Date: Mon, 24 Jan 2000 09:41:41 +0100 (CET) From: Andrzej Bialecki <abial@webgiro.com> To: Greg Lehey <grog@lemis.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: <Pine.BSF.4.20.0001240933180.46802-100000@mx.webgiro.com> In-Reply-To: <20000124121624.C2643@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Jan 2000, Greg Lehey wrote: > 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. Sometimes it's relatively easy, like with ssh. But try to do it with e.g. lynx, and you'll see what I mean. > > > 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. Yes, yes. My point was, that you have to have the full source tree each time you want to change something. wouldn't it be nice if the only things required to change the set of programs were an archive with prebuilt lots of utilities, from which you select only those components that are interesting, and simply copy the binaries to the floppy. No need to mess up with any source code. > > > 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. Yes, that's the case today. Notice, that I was speaking of using dynamic linking, instead of static, as we do it today. > > * 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. Erhm.. Not really. I think you're missing my point: the end result (which is a floppy that you will be able to boot your machine and use its hardware), instead of containing everything for everyone, can contain only the modules that you really need. You can do it yourself, e.g. by booting a minimal floppy which is able only to mount another floppy, from which you just copy the modules you will need to the original startup disk. How's that bigger than one-size-fits-all floppy we have today? > > 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 > > Andrzej Bialecki // <abial@webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- 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?Pine.BSF.4.20.0001240933180.46802-100000>