From owner-freebsd-hackers  Sun Oct 15 18:42:49 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id SAA22023
          for hackers-outgoing; Sun, 15 Oct 1995 18:42:49 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA22018
          for <hackers@freebsd.org>; Sun, 15 Oct 1995 18:42:45 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA05419; Mon, 16 Oct 1995 11:42:07 +1000
Date: Mon, 16 Oct 1995 11:42:07 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510160142.LAA05419@godzilla.zeta.org.au>
To: matt@lkg.dec.com, se@zpr.uni-koeln.de
Subject: Re: IPX now available
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>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