Date: Mon, 16 Oct 1995 11:42:07 +1000 From: Bruce Evans <bde@zeta.org.au> To: matt@lkg.dec.com, se@zpr.uni-koeln.de Cc: hackers@freebsd.org Subject: Re: IPX now available Message-ID: <199510160142.LAA05419@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>significant sense. However, when the world is dynamic the autoconfig >code now becomes passive and the LKMs are the active components. >Indeed, one very real way to look at this would be to use the DATA_SET >capabilities that currently exist to store a vector of configuration/ >initialization entries. So when the kernel is linked, all the >initializers for devices, file systems, protocols, etc. are present in >this data set. The system will define a set of synchronization points and >ordering points within each sync point. So when the kernel initializes, it >sorts these configuration entries and calls them one by one in order. >This results in a number of benifits. The first is that the exact same >modules can be used for both static-linked kernel and dynamically loaded >kernel. Another benifit is that you can develop and debug almost all >the mechanisms needed for a truly dynamic kernel using the existing static >kernel framework. I think this is backwards. I see linker vectors as just a trick to help initialize things when you don't have fully dynamic initialization. I think the static framework should be changed to look more like the dynamic framework instead of vice versa. >... >I strongly disagree. In my view, a LKM controls its own fate. The kernel >(or other LKMs on which this LKM depends) merely provided services which it >can use. Indeed, as far as the system is concerned there should be no >difference between a FS LKM or a device LKM or protocol LKM or a syscall LKM. >Once the LKM's configuration entry point has been called, the LKM is in >control. Yes, the dynamic framework (at least for device drivers) should be: . a single entry point (for initialization) in each module . autonomous modules The only difference for the static framework should be that the list of initialization routines is kept in a vector instead of in a file. Vectors aren't suitable for handling complicated orderings. The linker may put things in the wrong order so you need a meta-routine to decide the order or more intelligence in the module initialization routines. I think that except for early kernel initialization, all the intelligence should be in the module initialization routines. Device drivers will need to be able to sleep in their probe and attach routines for other reasons. When tsleep() at probe and attach time is implemented, complicated time-dependent orderings (aka races :-) will be easy to implemented - just sleep until the modules that you depend on are loaded. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510160142.LAA05419>