On Tue, Mar 9, 2021 at 5:19 PM Juraj Linkeš <juraj.lin...@pantheon.tech> wrote: > > > > > -----Original Message----- > > From: Bruce Richardson <bruce.richard...@intel.com> > > Sent: Tuesday, March 9, 2021 11:57 AM > > To: Juraj Linkeš <juraj.lin...@pantheon.tech> > > Cc: ruifeng.w...@arm.com; honnappa.nagaraha...@arm.com; > > phil.y...@arm.com; vcchu...@amazon.com; dharmik.thak...@arm.com; > > jerinjac...@gmail.com; hemant.agra...@nxp.com; > > ajit.khapa...@broadcom.com; ferruh.yi...@intel.com; abo...@pensando.io; > > lir...@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: > > > Honnappa, Thomas, Bruce, Jerin, you've comments in the past. Do you have > > any further input? > > > > > > 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? > > > > > > > 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).
+1 for allowlist. > > > 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 >
