Message-ID: <bc3278d8-f614-4a38-ba2e-ebc90268b9c8@lunn.ch>
Date: Sat, 7 Feb 2026 18:19:05 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Illusion Wang <illusion.wang@...ula-matrix.com>
Cc: Dimon <dimon.zhao@...ula-matrix.com>,
	Alvin <alvin.wang@...ula-matrix.com>,
	Sam <sam.chen@...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>,
	edumazet <edumazet@...gle.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: 回复：[PATCH v4 net-next
 02/11] net/nebula-matrix: add our driver architecture

On Fri, Feb 06, 2026 at 05:26:35PM +0800, Illusion Wang wrote:
> Last time sam had a question
> "
> 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"?"
> 
> There's no conclusion to this issue yet, so I haven't modified the 'core' parts for now
> (as mentioned in patch0)

This is all open source, you can do whatever you want with a fork of
Linux and out of tree drivers. Mainline has no influence about what
you do in your out of tree driver. So for Mainline, your out of tree
vendor driver does not really exist, any problems with it are yours to
solve.

However, Mainline cares about Mainline. We expect drivers which get
merged follow Mainline design principles, look like other mainline
drivers, and use naming consistent with other Mainline drivers.

You should also think about how this driver is going to be merged. It
is going to be in small pieces. It is very unlikely the first merged
patchset is actually useful for customers. You probably need quite a
few patchset merged before the driver is useful. If you have customers
who use Linus releases, they are going to have to deal with these WIP
driver. Such customers will be building the kernel themselves, so can
leave the in tree module out of the build. However, do most of your
customers use a distribution? A distribution is not going to update
its kernel until the next LTS kernel is release, sometime in
December. By then, you might have something usable in Mainline, and
the vendor driver is not needed. Or you might still be in the process
of rewriting the driver to Mainline standards and it is not
usable. Your customers then need to handle removing the mainline
driver and use the vendor driver. Again, that is not Mainlines
problem.

So, if your "core" driver is purely core, you can call it core, and
give it an empty tristate. The other drivers which are layered on top
of it can then select it.

If your "core" driver is actually an Ethernet driver, please drop the
name core.

     Andrew

Powered by blists - more mailing lists