linux-kernel - 回复：回复：回复：[PATCH v3 net-next 01/15] net/nebula-matrix: add minimum nbl build framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <17d3aa72-23a8-4ea8-9721-bc20fe39fdf4.sam.chen@nebula-matrix.com>
Date: Fri, 30 Jan 2026 11:31:27 +0800
From: "Sam" <sam.chen@...ula-matrix.com>
To: "Andrew Lunn" <andrew@...n.ch>
Cc: "Illusion Wang" <illusion.wang@...ula-matrix.com>,
  "Dimon" <dimon.zhao@...ula-matrix.com>,
  "Alvin" <alvin.wang@...ula-matrix.com>,
  "netdev" <netdev@...r.kernel.org>,
  "andrew+netdev" <andrew+netdev@...n.ch>,
  "corbet" <corbet@....net>,
  "kuba" <kuba@...nel.org>,
  "linux-doc" <linux-doc@...r.kernel.org>,
  "lorenzo" <lorenzo@...nel.org>,
  "pabeni" <pabeni@...hat.com>,
  "horms" <horms@...nel.org>,
  "vadim.fedorenko" <vadim.fedorenko@...ux.dev>,
  "lukas.bulwahn" <lukas.bulwahn@...hat.com>,
  "hawk" <hawk@...nel.org>,
  "ast" <ast@...nel.org>,
  "bpf" <bpf@...r.kernel.org>,
  "sdf" <sdf@...ichev.me>,
  "daniel" <daniel@...earbox.net>,
  "john.fastabend" <john.fastabend@...il.com>,
  "edumazet" <edumazet@...gle.com>,
  "open list" <linux-kernel@...r.kernel.org>
Subject: 回复：回复：回复：[PATCH v3 net-next 01/15] net/nebula-matrix: add minimum nbl build framework

Thank you for your feedback. You might have misunderstood me.
Our difficulties lie in the following:
1. Assuming only the mainline version changes the name (Assume name "nbl"),
   and our regularly released driver doesn't change its name, then when
   customers upgrade to a new kernel (containing the "nbl" driver),
   and then want to update our regularly released driver (named "nbl_core"),
   the module (ko) conflict will occur.
2. If both our mainline and regularly released drivers change their names,
   then customers who are already using the "nbl_core" driver will also
   encounter conflict issues when updating to the new driver "nbl".

Is it possible to do this: our net driver is also modified to be a driver based
on the auxiliary bus, while the PCIe driver only handles PCIe-related processing,
and these two drivers share a single kernel module (ko), namely "nbl_core"?
------------------------------------------------------------------
发件人：Andrew Lunn <andrew@...n.ch>
发送时间：2026年1月30日(周五) 11:04
收件人：Sam<sam.chen@...ula-matrix.com>
抄　送：Illusion Wang<illusion.wang@...ula-matrix.com>; Dimon<dimon.zhao@...ula-matrix.com>; Alvin<alvin.wang@...ula-matrix.com>; netdev<netdev@...r.kernel.org>; "andrew+netdev"<andrew+netdev@...n.ch>; corbet<corbet@....net>; kuba<kuba@...nel.org>; "linux-doc"<linux-doc@...r.kernel.org>; lorenzo<lorenzo@...nel.org>; pabeni<pabeni@...hat.com>; horms<horms@...nel.org>; "vadim.fedorenko"<vadim.fedorenko@...ux.dev>; "lukas.bulwahn"<lukas.bulwahn@...hat.com>; hawk<hawk@...nel.org>; ast<ast@...nel.org>; bpf<bpf@...r.kernel.org>; sdf<sdf@...ichev.me>; daniel<daniel@...earbox.net>; "john.fastabend"<john.fastabend@...il.com>; edumazet<edumazet@...gle.com>; open list<linux-kernel@...r.kernel.org>
主　题：Re: 回复：回复：[PATCH v3 net-next 01/15] net/nebula-matrix: add minimum nbl build framework

On Fri, Jan 30, 2026 at 10:23:50AM +0800, Sam wrote:
> Thank you for your feedback. I understand what you mean.The reasons why
> we cannot change the module name now are as follows:
> Our driver has already been integrated into multiple communities, and
> the module name is nbl_core. Many customers have already deployed it. If
> we change the name, there will be a critical problem of conflict between
> the two modules during subsequent online driver upgrades.

To a large extent, mainline does not care about your vendor driver,
and it does not care about any compatibility issues between your
vendor driver and mainline.

I've not looked at your driver in detail yet so i cannot comment on
your driver in particular. But we often see vendor drivers do things
mainline does not allow. Custom ioctl handlers, files in /sys, write
APIs in debugfs, statistic counters wrongly grouped, etc. In a vendor
driver this is O.K, this is all open source, you are free to do what
you want. But when it comes to mainline, you have to keep to the
mainline rules. Such code will need to be removed, or reworked,
breaking compatibility with your vendor driver.

So it can be advantages to have different names, it then become clear
if a customer is using the vendor driver, or is using mainline.

   Andrew