Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Aug 1995 17:49:29 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        bde@zeta.org.au, wollman@lcs.mit.edu, freebsd-current@FreeBSD.org, jhay@mikom.csir.co.za
Subject:   Re: pseudo device lkm's broken
Message-ID:  <199509010049.RAA23766@phaeton.artisoft.com>
In-Reply-To: <199508312149.HAA10464@godzilla.zeta.org.au> from "Bruce Evans" at Sep 1, 95 07:49:33 am

next in thread | previous in thread | raw e-mail | index | archive | help
> >> This can probably be fixed by adding a dummy ((caddr_t)NULL) arg to
> >> init() in the lkm PSEUDO_SET().  The correct fix is probably to
> >> get rid of the deprecated kernel PSEUDO_SET() and remove all the
> >> dummy args.  Even for boot-time sysinits, the args are almost
> >> always dummies.
> 
> >Deprecated by whom?  Certainly not me...
> 
> By Terry.  <sys/kernel.h> now says "To be deprecated after LKM is
> updated".
> 
> I committed the fix.

Let me explain this before this pisses people off.  There are a *lot*
of reasons for moving the whole kernel toward a linker_set based
model, and this will necessitate rolling in a lot of what is
currently handled by way of linker_sets into a unifiable data
description of the kernel onjects present in a kernel instance.

I expanded Garrett's initial work with linker_set structures to encompass
all of system initialization rather than just some aspects of it.

The proper way to deal with this in LKM will be to take the object
for the LKM and generate a post-processed linker_set reference so
that it doesn't vary the object module between loadable and statically
linkable forms.

This assumes agregations of a set into a single set by ld -r and a
change to the load image format for LKM's.

What this boils down to is a "foo.o" that can be loaded as a module
or thrown into the list of binary modules to be linked into the
kernel.

To implement this requires either a mod to ld, or, more preferrably,
a post-processing mechanism for the module object; you'd typically
want to deal with a module in the kernel in terms of export and
import lists in any case, so that you can build a dependency graph
that doesn't depend on link order, at the same time hiding the
module symbols that should not be depended upon by a clean use of
the module's exported interface.

The net effect is almost 0 on devices that use the devfs export
interface to register themselves as drivers and for file systems
that use the vfs_init mechanism to register themselves.  In point
of fact, all static device and file system initialization should
"go away", to be replaced by self-registration vi SYSINIT().  It's
really irrelevant for a lodable module as to whether the SYSINIT()
exported entry point is called by a loop in init_main.c or as a
side effect of the LKM load, so long as it is called.

One end goal is the elimination of all option #ifdef's in the kernel
(at least the ones not associated with debugging).  An option entry
in the config file will come to mean "generate the objects necessary
to make an obect of this name if it does not already exist, then
generate the object using ld -r, then include that object in the
list of objects you put together to get a kernel".

Yes, this is a pardigm shift.  It means that drivers and file systems
and anything else that is expected to be loadable or linkable as an
option to the kernel build must have a single entry/multiple consumer
interface with callback registration.  Anything that places itself
in a list of like objects is effectively using callback registration
right now, though optioned devices currently do this "registration"
statically using #ifdef's all over the code.  For most things, this
means little change over the current source tree as it stands.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509010049.RAA23766>