Date: Tue, 5 Mar 2013 08:15:30 -0700 From: Warner Losh <imp@bsdimp.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: arch@freebsd.org Subject: Re: revising sys/conf/files* dependencies Message-ID: <112844CF-69C3-49A3-8581-8EF2A7DA8E8A@bsdimp.com> In-Reply-To: <20130305083817.GD13187@onelab2.iet.unipi.it> References: <20130305083817.GD13187@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 5, 2013, at 1:38 AM, Luigi Rizzo wrote: > Short Summary: >=20 > I would like to revise sys/conf/files* and fix many erroneous usages = of >=20 > some/file.c optional foo_dev bar_bus >=20 > changing them into one of the following >=20 > some/file.c optional foo_dev # link error if bar_bus = is missing > some/file.cxi optional foo_dev | bar_bus # logical OR >=20 > ---------- > Full description: >=20 > I always thought (wrongly) that a line of the form >=20 > some/file.c optional foo bar baz # 1 >=20 > 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 >=20 > some/file.c optional foo | bar | baz # 2 >=20 > 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.: >=20 > 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) >=20 > 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 >=20 > 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 >=20 > 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. >=20 > "device da" implies "device scbus" >=20 > 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 ? >=20 > cheers > luigi > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?112844CF-69C3-49A3-8581-8EF2A7DA8E8A>