> From: Bruce Richardson [mailto:[email protected]] > Sent: Thursday, 22 January 2026 15.57 > > On Thu, Jan 22, 2026 at 02:47:47PM +0100, David Marchand wrote: > > On Thu, 22 Jan 2026 at 14:32, Bruce Richardson > > <[email protected]> wrote: > > > > > > On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote: > > > > > From: Bruce Richardson [mailto:[email protected]] > > > > > Sent: Thursday, 22 January 2026 13.24 > > > > > > > > > > Having the net_null driver always available can be convenient > and > > > > > allows > > > > > use by unit tests, so add this trivial driver to the always- > enable > > > > > list. > > > > > > > > > > Signed-off-by: Bruce Richardson <[email protected]> > > > > > > > > > > --- > > > > > I'm not sure if we want this to be always enabled or not, so > sending > > > > > this as an RFC. I can see definite advantages to doing so, but > I also > > > > > dislike having too many components on the always-enable list. > > > > > > > > > > Since I'm ambivilent myself, including this patch so the > community can > > > > > decide. > > > > > > > > I don't think real applications use this. > > > > If they do, they can include it manually. > > > > > > > > My main objection is: > > > > We are setting the wrong precedence if we make stuff like this > mandatory for convenience. > > > > > > > > But I agree with the reason you are suggesting it. > > > > > > > > Is there some other way it can be enabled for unit tests? > > > > Maybe the null driver can depend on the unit tests being built? > > > > > > > > I don't mind that the driver is being built. > > > > I just don't want it included by default when statically linking > a monolithic application. > > > > Same, I don't want a driver with almost no maintenance on it (even if > > it is trivial code) to be linked in a final application. > > (it would be a pity to get a CVE because of net/null ;-)) > > > > > > > > > > > > I'm flexible on this RFC, so it's a very soft NAK from me. > > > > If it can be disabled at build time, I'm OK with it. (But still > concerned about setting the wrong precedence.) > > > > > > > Yes, I agree. > > > > > > Why I'm proposing this is because, in order to give me faster > rebuilds and > > > because of the hardware I have available to me, I generally set up > my > > > builds with "-Denable_drivers=net/intel/*", since that really > speeds up my > > > dev-build-test cycle. In doing so, though, I do miss out on having > some > > > unit tests available when I run the fast-test suite, which is why I > > > suggested this addition in case there are others who limit the > builds to > > > just the hardware they are using. > > > > Unit tests are mainly run by the CI or DPDK developers, so how about > > putting this addition in the always enabled list under the > > developer_mode check? > >
I like this idea, but there's a similar risk of adding unnecessary stuff; now it's only limited to developer_mode. E.g. what else should be added in developer_mode to extend testing beyond what the developer explicitly configures? And what if the developer doesn't want these added tests (considering them a waste of time and resources)? > > Yep could work. Possibly also taking a modified version of Morten's > suggestion about warning about skipped tests, what about just emitting > a > warning from meson if we are in developer mode and we haven't the net- > null > driver enabled? I like this idea. But it requires some sort of coordination/synchronization between development of the test applications and the meson build script. I.e. when developing a new test case, dependencies need to be considered and possibly worked into the meson build script. This coordination will probably be forgotten. But even if forgotten, it will be remembered again next time a real need occurs.
