Date: Wed, 13 Jan 1999 13:31:23 +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.9901131316540.3476-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
(Ouch.. Sorry for the previous post - my fingers slipped...)
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
Again, why TCL? It's relatively HUGE....
> with a large vocabulary of TCL builtins for doing everything from
> "generic UI" work (e.g. uses serial/vty/??? style GUI as appropriate)
Ah... You think of using ctk instead of libdialog?
> 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
Have you already done this special hack, or is this just a speculation?
:-) I mean, it would be very useful to have something like this anyway...
> 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
^^^^^^^^^^^^^^^^
I don't get it.. Where copied 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.
Not only that - I have yet to discover how to minimize the _contents_ of
standard system libraries, because they usually contain much cruft you
don't need in case of this particular set of programs. The reason is that
when linking statically, all programs from boot.flp pull in something like
200kB from libc.a. When you do it dynamically, you would need to install
560kB of libc.so.3. So, that's why I had an idea of having separate set of
system libraries in full versions on a separate media, and to pull in only
the needed pieces which is required to run given set of programs. Perhaps
this is too cumbersome, though...
> 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.
Yes, definitely. Given the fact that normal boot.flp undergoes certain,
uhm, crisis right now, perhaps we should finally join our efforts and come
up with something which will be able to build (almost) any kind of
bootable floppy. How about it?
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.9901131316540.3476-100000>