Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Apr 2000 00:02:20 -0700
From:      Peter Wemm <peter@netplex.com.au>
To:        freebsd-arch@freebsd.org
Subject:   Re: How about building modules along with the kernel? (was: cvs commit: src/sys/modules/syscons/fire fire_saver.c src/sys/modules/syscons/rain rain_saver.c src/sys/modules/syscons/warp warp_saver.c) 
Message-ID:  <20000426070220.22F3F1CE1@overcee.netplex.com.au>
In-Reply-To: Message from "David O'Brien" <obrien@FreeBSD.org>  of "Tue, 25 Apr 2000 23:38:09 PDT." <20000425233809.C1022@dragon.nuxi.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
"David O'Brien" wrote:
> On Tue, Apr 25, 2000 at 10:40:23PM -0400, Chuck Robey wrote:
> > If you want, I'd do this myself this weekend.  I don't think the makefile
> > part is all that difficult.
> 
> At BSDcon we agreed that (1) the modules need to be built in a subdir of
> the kernel build dir; (2) they should be installed somewhere where their
> name matches the kernel name [/modules-kernel, /modules-kernel.old] for
> instance.  The machanism for finding modules files was never fully
> flushed out.

I kinda like Greg's /kernel/* suggestion.  But that's an installation issue
and not so much a 'how do we compile the damn things in the first place'.

Here's a nutshell description of things that are in the pipeline:

- config(8) is intended to mutate into a kernel+modules building tool,
where you can specify what you want in the static kernel and/or modules,
and which (if any) modules you want.

- config(8)'s function of doing device wiring is intended to be split out
into runtime-changeable configuration.  If you use loader(8), then it'll be
a plain text file in something like /boot/devicehints or /kernel/*/devicehints
or something.  The name doesn't matter at this point, but the key point is that
you will be able to edit this file and reboot without having to recompile
anything.  Hints will also be usable by device driver modules (eg: isa
drivers).  *however*..  It will also be possible to take this hints or
wiring file and generate a static table for compiling into a static kernel
so that you can boot a single self-contained kernel without having to use
loader (eg: from old netboot roms).  This would be equivalent to the present
config(8) style system where ioconf.c is generated and compiled in statically.

- modules (remember, a kld file may contain multiple modules) have version
tags embedded in them.  Each module may provide dependencies on other
module version tags.  This resolves the problems of having dependencies
moving between a static kernel and kld files, eg: the miibus module.  The
loader and kernel track which modules have been registered, what version id
tags they have, and what the dependencies are.  eg: if the kernel provides
the miibus module, then the loader will not bother looking for a file
containing the "miibus" module (which will usually be in miibus.ko but
doesn't have to be).  The versioning allows for safety checks against
mismatched calls.  If (for example) we made some incompatable change to the
VOP_* binary interface, we could force a recompile of every module that
made VOP_* calls if required and prevent people from shooting themselves in
the feet.  Because of the way the linker sorts and links the modules and
how the dependencies determine the symbol search orders, it's not out of
the question to have things like ABI "shims" - ie: two different versions
of the VOP_GETATTR symbols in the same kernel and have old kld's using the
old ABI via shims.  Of course, actually implementing this would be hell,
but it is possible :-).

How much of this is done?  A good deal of the module metadata (versions,
dependencies etc) code is done and pretty much ready for commit.  The
config(8) replacement stuff has more to do still but will not take long to
finish now.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




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