This patch adds a swap kernel commandline option, so that you can add a
swap partition before init starts running on a low-memory machine.
The patch is against 2.4.0-test11-pre7
This is my first try at a kernel patch so... I hope someone finds it
usefull.
Hi,
The Sat, Nov 18, 2000 at 01:46:40PM +0200, Kaj-Michael Lang wrote :
> This patch adds a swap kernel commandline option, so that you can add a
> swap partition before init starts running on a low-memory machine.
Did you try and add swap from an initrd image ? It should work and it's
already there.
--
Ueimor
On Sat, 18 Nov 2000, Francois romieu wrote:
> The Sat, Nov 18, 2000 at 01:46:40PM +0200, Kaj-Michael Lang wrote :
> > This patch adds a swap kernel commandline option, so that you can add a
> > swap partition before init starts running on a low-memory machine.
^^^^^^^^^^
> Did you try and add swap from an initrd image ? It should work
> and it's already there.
Did you try to load an initrd on a low-memory machine?
It shouldn't work and it probably won't ;)
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
Rik van Riel wrote:
> Did you try to load an initrd on a low-memory machine?
> It shouldn't work and it probably won't ;)
You must be really low on memory ;-)
# zcat initrd.gz | wc -c
409600
(ash, pwd, chroot, pivot_root, smount, and still about 82 kB free.)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
Werner Almesberger <[email protected]> writes:
> Rik van Riel wrote:
> > Did you try to load an initrd on a low-memory machine?
> > It shouldn't work and it probably won't ;)
>
> You must be really low on memory ;-)
>
> # zcat initrd.gz | wc -c
> 409600
>
> (ash, pwd, chroot, pivot_root, smount, and still about 82 kB free.)
Hmm.... And that's without trying to be small.
I have one that loads a second kernel over the network using dhcp
to configure it's interface and tftp to fetch the image and boots
that is only 20kb uncompressed....
Compressed I can fit that and a kernel all in plus a minimal
BIOS all in 512K with some room to spare...
Eric
Eric W. Biederman wrote:
> I have one that loads a second kernel over the network using dhcp
> to configure it's interface and tftp to fetch the image and boots
> that is only 20kb uncompressed....
Neat ;-) My goal is actually not only size, but also to have a relatively
normal build environment, e.g. my example is with shared newlib, regular
ash, and - unfortunately rather wasteful - glibc's ld.so.
But a tftp loader in 20kB is rather good. Now the next challenge is the
same thing with NFS. Then we can finally kill nfsroot ;-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
Werner Almesberger <[email protected]> writes:
> Eric W. Biederman wrote:
> > I have one that loads a second kernel over the network using dhcp
> > to configure it's interface and tftp to fetch the image and boots
> > that is only 20kb uncompressed....
>
> Neat ;-) My goal is actually not only size, but also to have a relatively
> normal build environment, e.g. my example is with shared newlib, regular
> ash, and - unfortunately rather wasteful - glibc's ld.so.
>
> But a tftp loader in 20kB is rather good. Now the next challenge is the
> same thing with NFS. Then we can finally kill nfsroot ;-)
Hmm. What does it take to mount an NFS partition?
Anyway. All I did was wrote a tiny libc that is just a bunch of
wrappers for syscalls, and some string functions. Then I just wrote
a straight forward C program to do the job. Except for my added
kexec call I can compile with glibc :)
Now if glibc wouldn't link in 200k of unused crap when you make a
trivial static binary I'd much prefer to use it...
Though I wish it was possible to have a ramfs preloader instead of
initrd. An initramfs would allow me to not even compile in the block
device driver layer, and be more efficient.
Eric
>===== Original Message From [email protected] (Eric W. Biederman) =====
>Werner Almesberger <[email protected]> writes:
>
>> Eric W. Biederman wrote:
>> > I have one that loads a second kernel over the network using dhcp
>> > to configure it's interface and tftp to fetch the image and boots
>> > that is only 20kb uncompressed....
>>
>> Neat ;-) My goal is actually not only size, but also to have a relatively
>> normal build environment, e.g. my example is with shared newlib, regular
>> ash, and - unfortunately rather wasteful - glibc's ld.so.
>>
>> But a tftp loader in 20kB is rather good. Now the next challenge is the
>> same thing with NFS. Then we can finally kill nfsroot ;-)
>
>Hmm. What does it take to mount an NFS partition?
>
>Anyway. All I did was wrote a tiny libc that is just a bunch of
>wrappers for syscalls, and some string functions. Then I just wrote
>a straight forward C program to do the job. Except for my added
>kexec call I can compile with glibc :)
>
>Now if glibc wouldn't link in 200k of unused crap when you make a
>trivial static binary I'd much prefer to use it...
>
>Though I wish it was possible to have a ramfs preloader instead of
>initrd. An initramfs would allow me to not even compile in the block
>device driver layer, and be more efficient.
>
A discussion on l-k two months ago revealed that someone actually had made a
patch that took a tarball (masquaraded as an initrd image) and unpacked it
into a ramfs. I've got the mail samewhere if you want it.
/Anders
Eric W. Biederman wrote:
> Hmm. What does it take to mount an NFS partition?
Mainly Sun RPC :-(
> Anyway. All I did was wrote a tiny libc that is just a bunch of
> wrappers for syscalls, and some string functions.
Certainly a good approach. It's also basically the idea behind newlib,
although newlib has more overhead.
Ultimately, I want to be able to compile regular Unix/Linux programs
out of the box. Right now, this works for a bunch of trivial programs,
and it almost works for ash.
> Now if glibc wouldn't link in 200k of unused crap when you make a
> trivial static binary I'd much prefer to use it...
Precisely why I went to newlib ... It's really a pity that glibc is
such a monster.
> Though I wish it was possible to have a ramfs preloader instead of
> initrd. An initramfs would allow me to not even compile in the block
> device driver layer, and be more efficient.
Hmm, this would be tricky. You could do it by implementing a simple
tar file reader in the kernel, which reads from /dev/initrd (well, it's
in-kernel representation), but I'm not sure if this buys you that much
in the end. (How much overhead is in block devices anyway ?)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
Hi1
> > Did you try to load an initrd on a low-memory machine?
> > It shouldn't work and it probably won't ;)
>
> You must be really low on memory ;-)
>
> # zcat initrd.gz | wc -c
> 409600
>
> (ash, pwd, chroot, pivot_root, smount, and still about 82 kB free.)
Your solution requires 400K initrd _plus_ memory for ash and swapon. That
might be easily 600K total. Yes I could imagine machine with freemem less
than that. However such machines do not usually have swap available.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.