From owner-freebsd-small Sun Jan 23 20:52:22 2000 Delivered-To: freebsd-small@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id B1CBE1582D; Sun, 23 Jan 2000 20:52:15 -0800 (PST) (envelope-from grog@mojave.worldwide.lemis.com) Received: from mojave.worldwide.lemis.com (j13.ktb6.jaring.my [161.142.234.27]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id PAA12833; Mon, 24 Jan 2000 15:21:50 +1030 (CST) (envelope-from grog@mojave.worldwide.lemis.com) Received: (from grog@localhost) by mojave.worldwide.lemis.com (8.9.3/8.9.3) id MAA02764; Mon, 24 Jan 2000 12:16:24 +0800 (MYT) (envelope-from grog) Date: Mon, 24 Jan 2000 12:16:24 +0800 From: Greg Lehey To: Andrzej Bialecki Cc: Andrew Hannam , small@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: One disk vs Two Disk (was Re: New approach to picobsd) Message-ID: <20000124121624.C2643@mojave.worldwide.lemis.com> Reply-To: Greg Lehey References: <005001bf6588$09fb8760$0104010a@famzon.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from abial@webgiro.com on Mon, Jan 24, 2000 at 12:09:43AM +0100 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 24 January 2000 at 0:09:43 +0100, Andrzej Bialecki wrote: > On Sun, 23 Jan 2000, Andrew Hannam wrote: > >>> Do we need to do it in one disk? >> The answer is a resounding "YES" for as long as possible. > > [lots of good suggestions] > >> With this problem solved I was able to remove such things as ee and more. >> The command line then becomes purely an "advanced" user fixit system. > > A couple of general thoughts: > > * current method of building: the way we do it right now, with crunchgen, > is relatively simple as long as you use system programs with well-formed > Makefiles and consistent build process. But even here there are a couple > of tough cases, Indeed. I don't know how easy it would be to include ports in the framework, for example. > to say nothing about what happens if you try to incorporate some > external utility. Also, this method doesn't allow for any modularity > (adding/removing programs without the need to rebuild everything > from sources). I don't understand this. You need to modify crunch.conf, but once you have done that, you just run make again, and it only builds the necessary files. > But this requires some clear path for how to build external utilities > (e.g. from ports) so that they work in this model. > > I don't have any clear picture how to do this. Last time I tried using > dynamic linking instead of static, it took so much more space that I gave > up immediately. Also, I didn't know how to minimize the set of symbols > from standard shared libraries to contain only those referenced by loaded > programs - if you don't do it, you need to use full standard libs which > are _big_. Is that correct? I thought crunch only included those library functions which were actually referenced, directly or indirectly, by the objects you included. But I haven't looked at the process that carefully. > * the step that we can already take is to make use of kernel modules, > instead of compiling everything into the kernel statically. Many ethernet > drivers can now be loaded on demand. We could include them on another, > "modules" floppy, freeing some space from the base floppies which would > contain the smallest subset of drivers possible. Then, you could download > the "base" floppy, "drivers" and combine them together to match your > hardware, without recompiling the whole stuff (which I see as a big > obstacle in using picobsd). This is a nice idea conceptually, but like with dynamic linking, the result is bound to be bigger. > BTW, I think this is something to be considered for installation > floppy as well. Jordan, are you listening? Agreed. > * incorporating more small, useful tools: recently I ported SASH which > will be great addition for setups like "router" floppy. I think SASH might have great potential in the "first or only" disk. It would be really nice to have a single disk which could be extended by further disks if you wanted. That would pave the way to a single "do it all" PicoBSD approach. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message