Date: Wed, 13 Jan 1999 03:17:04 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: Andrzej Bialecki <abial@nask.pl> Cc: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>, picoBSD <small@FreeBSD.ORG>, jkh@FreeBSD.ORG Subject: Re: Trinux (+ a proposal) Message-ID: <88207.916226224@zippy.cdrom.com> In-Reply-To: Your message of "Sat, 19 Dec 1998 16:42:08 %2B0100." <Pine.BSF.4.02A.9812191624150.24237-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> Whether we can beat that - well, this would require radically different > approach to our currently used model of crunched binaries. It's clever, > but too limiting. > > Recently I was thinking about it and I'm inclined to change this into > something more flexible, something along packages system. > > My idea is to have initially on startup a small (ca. 300-400kB) MFS > containing init and a package handling program. Then, the init would run > the packager, and this in turn would examine the list of wanted packages, > together with their space requirements. Then it would either create > appropriate MFS, mount it let's say on /usr/, and unpack all required > packages into this MFS; or, in case of bigger systems with HDD, just make > sure the required packages are present, and if not - perhaps install them > from some media (like HDD or network, or floppy). I think an approach _like_ this one is a good one, though I'm not sure you'd get away with just a straight unpacking of the binaries you need due to space constraints. My "ideal model" for this, when I sit thinking about stuff along these lines, always goes something like this: 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 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 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?88207.916226224>