From owner-freebsd-arch Wed Apr 26 11:42:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4949537B9B7 for ; Wed, 26 Apr 2000 11:42:49 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA14639 for ; Wed, 26 Apr 2000 20:42:43 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA04703 for freebsd-arch@freebsd.org; Wed, 26 Apr 2000 20:42:43 +0200 (CEST) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 10C9837B96D for ; Wed, 26 Apr 2000 11:40:39 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA20532; Wed, 26 Apr 2000 11:40:25 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAAvNa44N; Wed Apr 26 11:40:10 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id LAA06879; Wed, 26 Apr 2000 11:40:14 -0700 (MST) From: Terry Lambert Message-Id: <200004261840.LAA06879@usr09.primenet.com> Subject: Re: How about building modules along with the kernel? To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 26 Apr 2000 18:40:13 +0000 (GMT) Cc: doconnor@gsoft.com.au (Daniel O'Connor), freebsd-arch@freebsd.org In-Reply-To: <00042604130602.06932@nomad.dataplex.net> from "Richard Wackerbarth" at Apr 26, 2000 04:13:06 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The loader can (and does) already read UFS.. > > > > It can read files in and load them into arbitarily named sections in the > > kernel, and other good things :) > > But what about JFS, E2FS, KFS, etc. ? Historical UNIX implementations have handled this with a flat filesystem, usually called "stand", where the kernel and any modules needed to access the locally instantiated filesystem implementations are installed. NT's boot loader approaches this the same way, though their "stand" is actually a FAT partition. At this point, it might be just as easy to use "FAT" for this, since many architectures have a requirement for FAT support anyway, or minimally, DOS partitioning. Both the PReP and Open Firmware, as well as the Alpha ARC BIOS, have these requirements for example. In general, one might consider an ELF section archiver, which can modify an ELF module to include support for any filesystem module of your choice, at boot and kernel installation time; this kind of assumes the ability to bootstrap to an ELF module. Some older systems, and some current Linux systems, and NetBSD, at least at one time, used knowledge of the linear sector address of kernel sectors, in order to load the kernel from wherever it happened to be stored, completely ignoring the filesystem format. This seems less flexible than the "stand" approach. NB: "stand" does not mean "/stand", it means a seperate partition set aside for the boot loader, which the boot loader would always be able to understand, regardless of what you did to the format of the rest of the disk. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message