From owner-freebsd-small Wed Jan 13 03:30:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27313 for freebsd-small-outgoing; Wed, 13 Jan 1999 03:30:48 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA27287; Wed, 13 Jan 1999 03:30:44 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id MAA26760; Wed, 13 Jan 1999 12:35:57 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Wed, 13 Jan 1999 12:35:57 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: "Jordan K. Hubbard" cc: Jeroen Ruigrok/Asmodai , picoBSD , jkh@FreeBSD.ORG Subject: Re: Trinux (+ a proposal) In-Reply-To: <88207.916226224@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 13 Jan 1999, Jordan K. Hubbard wrote: > The kernel comes up, finds small MFS image im memory (say <2MB), > mounts it as root and runs the "bootstrapper" tool from MFS. The > bootstrapper is a single init(8) replacement which is quite > intelligent - it has a TCL interpreter in it for running scripts along TCL??? Ewww... Ok, personal preferences aside, but still: it's *HUGE* ! > with a large vocabulary of TCL builtins for doing everything from > "generic UI" work (e.g. uses serial/vty/??? style GUI as appropriate) > to locating any number of "media" types, such as an NFS filesystem, an > FTP connection or a CDROM. One of the first thing this bootstrapper > does is create another MFS, but this time a very special one. This > MFS would be a hacked MFS which allowed dynamic sizing. The initial > size allocation would be between 20-40% of available memory, depending > on memory size. This MFS, perhaps mounted as /usr, would be used to > store binaries as required, presumably loaded by the bootstrapper from > one of its available media types. If you run up against the end of > MFS and the system says "yes" to your "give me more memory!" request, > you can also then grow the MFS accordingly. Since things run out of > the MFS don't get copied, it actually isn't such a dire scenario to > contemplate this second MFS growing to occupy a significant percentage > of main memory. If you implement "shrink" in your new dynamic MFS, it > would even be possible to compact it again after, say, being asked to > load and run something like emacs. :-) > > As to the binaries themselves, you basically want to come up with your > own variant of RTLD. Instead of printing a diagnostic and falling > over when something demands a shared library which isn't available, as > it does now, you simply grab the shared library on demand, stick it in > your shared library cache, and proceed with the requested operation. > Shared executables and their dependent shared libs aren't actually the > most efficient way of transporting executables but, as you've noted > yourself, crunched binaries are just too inflexible and difficult to > build. You ideally just want to be able to say "here's a binary, > please grab and run it", throwing it away later when you either need > the memory or have something which needs it more urgently (overlays). > > I'm still working on the "bootstrapper" as part of the work we're > doing for the new sysinstall since what sysinstall needs to do and > what picobsd needs to do are very similar things, when you come right > down to it. I need to put up lots of dialogs and conditionally launch > binaries like ppp, depending on the installation type, just as picobsd > does. > > - Jordan > Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message