RFC: Correct location for SUBsystem-wide options ?

[Julian Elischer]

On 7/4/11 2:09 AM, Luigi Rizzo wrote:
> Hi,
> in the process of deciding where to put the kernel option for NETMAP,
> i have looked at the current practice, and i see a bit of confusion
> on how things are done.
>
> Looking at the comment at the top of sys/conf/options we have
> * opt_foo.h             for options affecting a single source file foo.[cs]
> * opt_some_name.h       for option SOME_NAME affecting only a few files.
>    <GAP_HERE>             for options affecting many but not all files
>                          (e.g. all network interfaces)
> * opt_global.h          for system-wide options
>
> So, we have no standard place for options affecting all network
> interfaces, which are exactly the thing i am looking at, and I
> see all possible varieties in our sys/conf/options:
>
> INET, INET6     go into their own headers (opt_inet.h and opt_inet6.h)
>                  In my view these are system wide in the sense that
>                  INET support may use some specific code also in
>                  device drivers, e.g. all the checksum and tcp offloading
>                  support
>
> DEVICE_POLLING  goes into opt_device_polling.h
> NETGRAPH        goes into opt_netgraph.h
>
> ALTQ, VIMAGE    go into opt_global.h
>                  (note that internal ALTQ_* options are in opt_altq.h)
>
>
> Missing a specific header opt_network.h, in my opinion the correct
> approach is the one used for ALTQ and VIMAGE: they properly go
> into opt_global.h, and we should move there also INET, INET6,
> DEVICE_POLLING and NETGRAPH (and DEV_NETMAP).
Netgraph was written to be a completely self standing set of code,
completely loadable as modules. So it got ists own ,h

VIMAGE needs to affect files all over the place do so we put it in
opt_global.h. (we originally had opt_vimage,h) to minimize
th work people needed to do to add vimage support. I can not be loaded 
as a nodule.

> This way we reduce the clutter in all the if_*.c files, and
> also avoid the risk that one of these files forgets to include
> a required opt_something.h
>
> In any case, it is not my intention to modify the status quo,
> but at least add a proper suggestion in sys/conf/options
> to deal with these cases.
>
> Comments ?
>
> 	cheers
> 	luigi
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>