From owner-freebsd-hackers Sat Sep 30 12:46:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14017 for hackers-outgoing; Sat, 30 Sep 1995 12:46:37 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA14012 for ; Sat, 30 Sep 1995 12:46:36 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id MAA00312; Sat, 30 Sep 1995 12:46:09 -0700 Message-Id: <199509301946.MAA00312@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: dennis@etinc.com (dennis) cc: "Justin T. Gibbs" , jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 15:45:04 EDT." <199509301945.PAA06042@etinc.com> Date: Sat, 30 Sep 1995 12:46:08 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >>>>Fixing LKMs (something even people with more than 4MB want) should take >>>>care of this. >>>>-- >>> >>>It really shouldn't. I think that what is needed is a "bootload" kernel and >>>a "generic" >>>kernel. While its ok for the generic kernel to be large, the "bootload" >>>should allow someone to >>>load the system and compile (or load) a custom kernel, which can be much >>>smaller. There's no >>>reason why the generic kernel has to be used on the boot floppy. >> >>I respectfully disagree. ;-) >> >>The "boot kernel" should have enough glue to load LKMs for anything from >>NFS support to your favorite SCSI driver off of the boot floppy (or even >>additional floppies). The LKM for device drivers should have an entry >>point that lets you determine presence of the hardware before committing >>the whole module to memory. In this way, a "generic" boot floppy could >>cycle through all LKMs asking them to do the probe and only load the full >>module (or perhaps unload the module in the event of failure) if the probe >>is successful. In this way, the only way you'd not be able to install >>in a low memory configuration is if you had everything but the kitchen >>sink in your machine. >> >>I want to move toward a more dynamic system where >>in most cases you don't have to recompile the kernel to get the right >>configuration for you system. LKMs seem the natural solution. > >This is a lofty goal that requires not only that LKMs be substantially >improved, but that every >driver (almost) be implemented as a loadable module and that the modules be >extremely clean and non-destrucitve. While this is certainly possible, its >not a solution for today I never said that it was a solution for today... only that fixing LKMs properly should make this problem "go-away". How Jordan deals with making 2.1 install in 4MB is his business. The rest of us can work on making my "lofty goal" a reality for 2.2 or 2.3. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations ===========================================