Date: Mon, 24 Jan 2000 12:16:24 +0800 From: Greg Lehey <grog@lemis.com> To: Andrzej Bialecki <abial@webgiro.com> Cc: Andrew Hannam <famzon@bigfoot.com>, 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> In-Reply-To: <Pine.BSF.4.20.0001232335180.43769-100000@mx.webgiro.com>; from abial@webgiro.com on Mon, Jan 24, 2000 at 12:09:43AM %2B0100 References: <005001bf6588$09fb8760$0104010a@famzon.com.au> <Pine.BSF.4.20.0001232335180.43769-100000@mx.webgiro.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000124121624.C2643>