Date: Wed, 13 Jan 1999 16:34:53 +0100 (CET) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: jkh@FreeBSD.ORG, picoBSD <small@FreeBSD.ORG>, Andrzej Bialecki <abial@nask.pl> Subject: Re: Trinux (+ a proposal) Message-ID: <XFMail.990113163453.asmodai@wxs.nl> In-Reply-To: <88207.916226224@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Dunno if the extra jkh@freebsd.org was intentional, so I maintained it ]
On 13-Jan-99 Jordan K. Hubbard wrote:
>> 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:
Well, since kzip has been fubared by the ELF transition, do we have a
suitable replacement anyway for the unpacking? Or am I thinking in the
wrong unpacking terms?
> 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.
OK, dumb remark mayhaps, but what would be the benefit of using different
scripting languages for every nook and cranny in the OS? I mean, we're
using Forth in the new boot{loader|strapper|configuration} and then we are
going to use TCL for the install stuff? True, if enough justification can
be given for one of the languages as being the ultimate for a given goal
then I have to agree =)
What I am aiming at it is that we do have to watch for thoughts that will
try to get every scripting language used in FreeBSD because it's so easy to
use with this or that. Plus we do have to watch base OS bloating as well...
> 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. :-)
Jordan, you are referring to the shrink/grow abilities such as VxFS and JFS
them have (JFS can only grow I thought)?
> 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).
Sorry, RTLD? Real-Time LoaDer?
Also, how do ye mean the sentence: "you simply grab the shared library on
demand, etc..."?
> 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.
Aye, indeed... How modular is sysinstall now btw? Because we might need to
create more modular pieces regarding install and such. Off course, not
having looked at the code yet, I might be blabbering ;)
---
Jeroen Ruigrok van der Werven A veil of smoke is what I am,
asmodai(at)wxs.nl I wait and I wait...
Network/Security Specialist <http://home.wxs.nl/~asmodai>;
BSD & picoBSD: The Power to Serve <http://www.freebsd.org>;
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?XFMail.990113163453.asmodai>