From owner-cvs-all Wed Apr 26 0: 2:40 2000 Delivered-To: cvs-all@freebsd.org Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id C2C2537BB1E; Wed, 26 Apr 2000 00:02:20 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 22F3F1CE1; Wed, 26 Apr 2000 00:02:20 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: obrien@FreeBSD.org Cc: Chuck Robey , Greg Lehey , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Reply-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) In-Reply-To: Message from "David O'Brien" of "Tue, 25 Apr 2000 23:38:09 PDT." <20000425233809.C1022@dragon.nuxi.com> Date: Wed, 26 Apr 2000 00:02:20 -0700 From: Peter Wemm Message-Id: <20000426070220.22F3F1CE1@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "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 cvs-all" in the body of the message