RFC: Correct location for SUBsystem-wide options ?

[Masao Uebayashi]

I think that conditional build switches belong to modules.  If FreeBSD
designs kernel carefully so that it can run without network support at
all, "network" can be said  a module, and network interfaces are
modules depending on "network".  Then network related build switches
don't need to be global.

On Mon, Jul 4, 2011 at 6:09 PM, Luigi Rizzo <rizzo at iet.unipi.it> 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).
>
> 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"
>