Thread (463 messages) 463 messages, 15 authors, 2021-04-15

Re: [dpdk-dev] [PATCH v16 1/3] build: disable/enable drivers in Arm builds

From: Juraj Linkeš <hidden>
Date: 2021-03-09 11:49:55

-----Original Message-----
From: Bruce Richardson <redacted>
Sent: Tuesday, March 9, 2021 11:57 AM
To: Juraj Linkeš <redacted>
Cc: Ruifeng.Wang@arm.com; Honnappa.Nagarahalli@arm.com;
Phil.Yang@arm.com; vcchunga@amazon.com; Dharmik.Thakkar@arm.com;
jerinjacobk@gmail.com; hemant.agrawal@nxp.com;
ajit.khaparde@broadcom.com; ferruh.yigit@intel.com; aboyer@pensando.io;
lironh@marvell.com; dev@dpdk.org
Subject: Re: [PATCH v16 1/3] build: disable/enable drivers in Arm builds

On Tue, Mar 09, 2021 at 08:58:39AM +0000, Juraj Linkeš wrote:
quoted
Honnappa, Thomas, Bruce, Jerin, you've comments in the past. Do you have
any further input?
quoted
I think we just need to agree on the allowlist/blocklist mechanism. The current
commit allows specifying either an allowlist or a blocklist, but not both.
However, it would possible to implement specifying both - first we'll allow
what's in allowlist and then we'll remove from that set what's in blocklist.
Thoughts?
quoted
If we have both, I think limiting to only one is by far the sanest option.
I'm not fully convinced by the need to have both, since the blocklist allows
wildcarding and exception cases. For example "net/[!i]*" will blocklist all net
drivers except those starting with an "i". Admittedly, for usability purposes
having an allowlist might work better.
If we only want to build a handful of drivers then the list could be very long (which was the original reason behind having an allowlist), such as here:
https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=build/external/packages/dpdk.mk;h=c35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=HEAD

An allowlist could also help with maintenance - users won't need to add new drivers to their blocklists (if that's what users need, like in the case of VPP).
One final thought, if we add a driver allowlist for cross files, should we also add
one as a top-level meson option also for consistency?
This definitely makese sense. I was thinking about this and wasn't sure whether I should put it into this commit or a separate one. The commit evolved a bit and now that it's just an implementation of an allow/blocklist it makes sense to include a meson option in it I think - I'll put it into the next version.
/Bruce
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help