From owner-freebsd-hackers Sun Dec 14 23:51:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01793 for hackers-outgoing; Sun, 14 Dec 1997 23:51:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA01781 for ; Sun, 14 Dec 1997 23:50:58 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712150750.XAA01781@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA241052236; Mon, 15 Dec 1997 18:50:37 +1100 From: Darren Reed Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: gurney_j@resnet.uoregon.edu Date: Mon, 15 Dec 1997 18:50:36 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, hackers@FreeBSD.ORG In-Reply-To: <19971214225639.55532@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 14, 97 10:56:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from John-Mark Gurney, sie said: > > hmm... here's a question for you... > how much kernel work have you done in making the freebsd kernel as small > as possible?? with the changes that I'm working on... the ONLY things > neccessary in a static kernel will be the boot device (be it network > card or hard disk), and file system for modules... then the rest will > be dynamicly loaded... Well, the Solaris2 kernel is 600k (/platform/sun4m/kernel/unix) for 2.5.1, but /platform/sun4m is 4.5M in size with another 1.5M in /usr/kernel. Personally, I find as the number of files required to boot into single user increases, the greater the chance of shit happening on a bad crash and the system becoming unable to boot itself. Personally, I think that the boot device and root fs should always be "in" the kernel so that if someone has nuked all your modules, you can still get up into single user mode. I think that whilst the above goal is interesting (and perhaps worthwhile), there are already problems which need to be solved for LKM's which aren't, as yet, such as merging LKM symbols so that gdb on the kernel is sane and fixing up crash dumps.. Darren