revising sys/conf/files* dependencies

[Warner Losh]

On Mar 5, 2013, at 1:38 AM, Luigi Rizzo wrote:

> Short Summary:
> 
> I would like to revise sys/conf/files* and fix many erroneous usages of
> 
>    some/file.c		optional foo_dev bar_bus
> 
> changing them into one of the following
> 
>    some/file.c		optional foo_dev # link error if bar_bus is missing
>    some/file.cxi	optional foo_dev | bar_bus # logical OR
> 
> ----------
> Full description:
> 
> I always thought (wrongly) that a line of the form
> 
> 	some/file.c	optional foo bar baz		# 1
> 
> in sys/conf/files* meant that file.c is compiled in if _any_ of the
> options is specified in the kernel config. But i was wrong, the
> above means that _all_ options are require, and the correct syntax
> for alternative options is
> 
> 	some/file.c	optional foo | bar |  baz	# 2
> 
> I believe that i am not alone in this misunderstanding, and that
> most entries in sys/conf/files* use form #1 in a wrong way, e.g.:
> 
>    dev/hptiop/hptiop.c             optional hptiop scbus
>    dev/iscsi/initiator/iscsi.c     optional iscsi_initiator scbus
>    dev/mfi/mfi_cam.c               optional mfip scbus
>    pci/viapm.c                     optional viapm pci
>    pci/intpm.c                     optional intpm pci
>    pci/if_rl.c                     optional rl pci
>    (there are many many more)
> 
> In all these cases, if you forget the scbus or pci in the kernel
> config, the driver is not compiled in but you only detect it at
> compile time. I'd rather be notified of the error at kernel link time.

I'd say those are correct: don't compile if_rl unless you have both rl and pci in the kernel....  There's no misunderstanding here: people know what it means.

> So, as said in the summary, I'd like to modify these and similar
> lines so that the error notification comes early; normally
> this is achieved by removing the bus name.

That might be OK. The original intent for this form was to allow one to remove all pci drivers from the kernel by just removing the device pci line from the config file. This is at best a dubious feature, experience has shown. I'm worried that "fixing" it will produce a worse problem than the one you are fixing.

> Probably the only case where the "AND" form makes sense is when two
> "device ..." entries in the kernel config also need to bring in
> some additional files. Examples (perhaps) are drivers which support
> multiple buses, such as
> 
>    dev/an/if_an.c                  optional an
>    dev/an/if_an_isa.c              optional an isa
>    dev/an/if_an_pccard.c           optional an pccard
>    dev/an/if_an_pci.c              optional an pci
> 
> but this does not seem the main usage.

Yea. One problem with your suggestion though. Some busses, like pccard, are totally loadable. you won't get an error if you don't have pccard in the kernel, but if you stick a an card into the system it won't probe either. In at least the case of pccard, that's intentional so that you can load/unload pccard at runtime if you were debugging it :)

> It would be really good if we could force dependencies, e.g.
> 
>    "device da" implies "device scbus"
> 
> but there is no good way to specify this in sys/conf/files* without
> horribly cluttering the entries for a bus with all the devices
> that use it.

Yes.

> Probably one could extract this information from the MODULE_DEPEND() macros

Probably not. there are many conventions, but they are violated often enough to not be automateable.

> within the source tree, but i am unclear on what is the most
> efficient way to process the information without having to change
> config(8) -- which being written in C is a bit error-prone.

Well, hacking config is error prone not because it is written in 'C', but because it is in a style that people stopped writing in sometime in the late 1980's because it was error-prone.

> 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"