From: Michele Andreoli (m.andreoli@tin.it)
Date: Thu Nov 16 2000 - 13:54:00 CET
On Wed, Nov 15, 2000 at 07:55:23PM +0100, Dumas Patrice nicely wrote:
> Hi,
> I have had an idea for 4Mo machines, so that it is not mandatory to
> clone mulinux on these computers.
>
> Basically, the idea is to have root uncompressed on a floppy like what
> is done for installation on such computers, and load in ramdisk only
> some files, but not the entire /usr (or add-ons, but...).
>
> When there is a need of a file that is not in ram, the user is prompted
> to put the right floppy and the file is loaded in ram. I have no clear
> idea on how to implement such a system, nor wether it would be too slow
> or not.
This feature is already in the current muLinux. Using the script
"maker.bat" (make root), it create a floppy disk (ROOT) with the
root filesystem in it, but in plaintext, i.e. not compressed, i.e.
moutable.
If the user now run "lowmem.bat", the kernel will ask "please, put
the root floppy in the drive". The root is mounted, WITHOUT any
kind of ramdisk.
I explained that in the list, time ago.
> In memory, there would be
> kernel+libc5+/tmp+modules+some frequently used files of the root floppy
> (ash, sed, grep, echo, cd, ls...)+whatever the user use.
> ?+ 432684 + 300000 + ? + 55704 + not a lot. I think it could be good,
> something like 2Mo.
If you really try to do that (as I did), you will find the muLinux root.gz
archive: this is my bare minimum able to run a script in Linux!!
> As every programm used then would take twice his
> place in ram (one time on the ramdisk, one time in ram), it would be not
> too hard to compute the size of the ramdisk, with some extra space for
> datas of progs. If 1Mo is left for datas, there could be 500k of running
> programs at one time, not so much, but sufficient, no ?
>
> But there are some technical issues left :
> 1) how to know that a file wasn't found, then launch a prog that loads
> it in the ramdisk and the execution of the first one continue... I think
> that a wrapper around ash that detects ash's "file not found" shouldn't
> be sufficient, as the programm would be stopped.
You forget an important point: 386 with 4M stops with "can't fork()"
very quickly, after boot! They aren't able to run anything, so they
can't run the command that unpack in the way you explained :-(
>
> Maybe it could be possible to hack the ash code so that when there is a
> file not found ash starts another prog that loads the ram disk ? It
> would be something like a "disk change feature" for the shell.
>
> 2)assuming this step is done, theree should be a program that
> - knows wether the file needed exists anywhere
> - extract it from a floppy and put it in ram.
Please, read my previous sentence. I used this mechanism only for
kernel modules: they are loaded from the floppy "on demand".
> the first step would necessitate a database of all the files in mulinux
> in root disk.
> for the second step, I don't know how to do ! Maybe the use of what you
> spoke about, Michele, an offset database in the first block(s) of a
> floppy, and then a dd to get the right file.
Again: the 386/4M is unable to issue the "dd" command as you said.
It is unable to issue a swapon!
If you plan to do that with scripts, you have no hope. CAN'T FORK
will be the result. The only solution is to write the /linuxrc in C.
Michele
-- In summing up, I wish I had some kind of affirmative message to leave you with, I don't. Would you take two negative messages? - Woody Allen --------------------------------------------------------------------- To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:16 CET