Date: Wed, 13 Jan 1999 12:35:57 +0100 (CET) From: Andrzej Bialecki <abial@nask.pl> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>, picoBSD <small@FreeBSD.ORG>, jkh@FreeBSD.ORG Subject: Re: Trinux (+ a proposal) Message-ID: <Pine.BSF.4.02A.9901131231220.5148-100000@korin.warman.org.pl> In-Reply-To: <88207.916226224@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -------------------- ++-------++ ------------------------------------- <abial@nask.pl> ||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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9901131231220.5148-100000>