netdev - Re: 回复：回复：[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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ecbf1ba5-6ef9-4d94-8240-518852050f03@lunn.ch>
Date: Fri, 30 Jan 2026 04:04:31 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sam <sam.chen@...ula-matrix.com>
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: 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