[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c1536b51-f441-45ca-8bfb-d5f7d8230713@lunn.ch>
Date: Thu, 29 Jan 2026 14:18:44 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Illusion Wang <illusion.wang@...ula-matrix.com>
Cc: y <y@...n.ch>, 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>, 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 Mon, Jan 26, 2026 at 10:18:52AM +0800, Illusion Wang wrote:
>
> >_CORE is a bit unusual for a driver. CORE is generally a library which
> >is shared by a number of drivers. It does not have a tristate string,
> >it is just selected by the drivers which need it.
>
> Thank you for your feedback on the NBL_CORE configuration option. We appreciate
> your guidance on adhering to Linux kernel naming conventions.
>
> Why NBL_CORE?
> The driver is designed to support two distinct functionalities for the
> Nebula-matrix m18100 Ethernet controller:
>
> 1.Standard Ethernet/NIC functionality (via the main driver module).
> 2.Auxiliary device (auxiliary driver) for RDMA (exposed through
> auxiliary_device).
> 4.MDEV-based SR-IOV/VF emulation (for native device splitting).
> Since shared logic (e.g., PCIe resource management, MMIO access, interrupt
> handling, and common hardware abstractions) is required across both the main
> driver and auxiliary/RDMA driver, we opted for a _CORE suffix to indicate:
You can split this two ways:
A true core, which does not provide any devices, just core functions
to access the hardware. Then layered on top if this you have kernel
modules with provide Ethernet, RDMA, MDEV etc. Such kernel modules
would then depend on the core, using Kconfig primitives. And the core
itself would not have a tri-state string, since on its own it is
useless.
Or
If the core always provides Ethernet, call it an Ethernet driver, not
core. The other kernel modules would then depends on having the
Ethernet driver, using Kconfig primitives.
This all about naming, not architecture. Splitting it up into multiple
kernel modules is good, but your naming and descriptions of what these
modules do matters.
Andrew
Powered by blists - more mailing lists