<snip>

quoted

quoted

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.

quoted

quoted

Thoughts?

quoted

If we have both, I think limiting to only one is by far the sanest option.

+1

quoted

quoted

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.

quoted

quoted

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:

quoted

https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=build/external/packag
es/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.

May be I am missing something here. By creating an allowlist, does it mean drivers are disabled (from compilation) by default? For a server platform, where almost all the drivers can be compiled, does the allowlist contain all the drivers?

If we assume by default everything should compile on Arm platform, but allow for few exceptions (where things are really painful to fix, for ex: compiler needs to be fixed), having a blocklist should be shorter/better?

By having an allowlist, we will end up with a large part of the code that might not compile on Arm platforms.

quoted

quoted

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.

quoted

quoted

/Bruce