From: Russell King <hidden> Date: 2003-03-06 23:08:40
On Fri, Mar 07, 2003 at 12:13:57AM +0000, Alan Cox wrote:
On Thu, 2003-03-06 at 22:25, Russell King wrote:
quoted
quoted
quoted
The right fix is to delete ipconfig.c, it has been the right fix for a long
long time. There are initrd based bootp/dhcp setups that can also then mount
a root NFS partition and they do *not* need any kernel helper.
The klibc tarball on kernel.org also has ipconfig-type code, waiting for
initramfs early userspace :)
Many have wanted to delete ipconfig.c for a while now...
Yep, can't the deletion wait a couple more weeks or so until klibc gets
merged? It's not like ipconfig.c is broken currently, is it?
Thats how it ended up in 2.4. Klibc doesnt really matter, the apps exist
linked with dietlibc and stuff even without klibc.
Time for it to die
"klibc doesnt really matter"
I'd prefer not to have to have thousands of special programs around
just to be able to boot my machines, especially when it was all in-
kernel up until this point.
klibc yes, dietlibc with random other garbage in some random filesystem
which'd need maintaining - no thanks.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
"klibc doesnt really matter"
I'd prefer not to have to have thousands of special programs around
just to be able to boot my machines, especially when it was all in-
kernel up until this point.
klibc yes, dietlibc with random other garbage in some random filesystem
which'd need maintaining - no thanks.
You can build the dhcp client with glibc static into your initrd. Its hardly
magic or special programs or random garbage, and last time I counted it came
to one program. Dunno what the other 999 utilities your dhcp needs are ?
From: Michael Mueller <hidden> Date: 2003-03-07 07:05:30
Hi Alan,
you wrote:
quoted
I'd prefer not to have to have thousands of special programs around
just to be able to boot my machines, especially when it was all in-
kernel up until this point.
klibc yes, dietlibc with random other garbage in some random filesystem
which'd need maintaining - no thanks.
You can build the dhcp client with glibc static into your initrd. Its hardly
magic or special programs or random garbage, and last time I counted it came
to one program. Dunno what the other 999 utilities your dhcp needs are ?
Sorry, but I must join Russel here. I have atleast one machine which has
a bootloader able to load exactly one file only. There is currently no
way to load an initrd. It would need to implement the whole (BOOTP+)TFTP
stuff again, just to get the initrd. So I was quite happy linux 2.4
still knows about mounting a NFS root filesystem without user-space
help.
Michael
"klibc doesnt really matter"
I'd prefer not to have to have thousands of special programs around
just to be able to boot my machines, especially when it was all in-
kernel up until this point.
klibc yes, dietlibc with random other garbage in some random
filesystem which'd need maintaining - no thanks.
You can build the dhcp client with glibc static into your initrd.
Anything built static against glibs tends to be 400K+.
--
vda
On Fri, 2003-03-07 at 07:15, Michael Mueller wrote:
Hi Alan,
Sorry, but I must join Russel here. I have atleast one machine which has
a bootloader able to load exactly one file only. There is currently no
way to load an initrd. It would need to implement the whole (BOOTP+)TFTP
stuff again, just to get the initrd. So I was quite happy linux 2.4
still knows about mounting a NFS root filesystem without user-space
help.
Just glue the initrd to the kernel. This is not rocket science
From: Michael Mueller <hidden> Date: 2003-03-07 21:24:12
Hi Alan,
you wrote:
quoted
Sorry, but I must join Russel here. I have atleast one machine which has
a bootloader able to load exactly one file only. There is currently no
way to load an initrd. It would need to implement the whole (BOOTP+)TFTP
stuff again, just to get the initrd. So I was quite happy linux 2.4
still knows about mounting a NFS root filesystem without user-space
help.
Just glue the initrd to the kernel. This is not rocket science
Do you have a sort of glue fixing the ramdisk support on m68k to support
physically non-continous memory too? Otherwhise I have only 1 MiB for
the whole initrd.
So hopefully the removal of ipconfig.c, if decided for, does not
propagate back into the 2.4 series. It would add a heap of useless work
to do, just to get it up again.
Michael
--
Linux@TekXpress
http://www-users.rwth-aachen.de/Michael.Mueller4/tekxp/tekxp.html
From: Arnaldo Carvalho de Melo <hidden> Date: 2003-03-09 04:35:14
Em Fri, Mar 07, 2003 at 12:54:36PM +0000, Alan Cox escreveu:
On Fri, 2003-03-07 at 07:15, Michael Mueller wrote:
quoted
Hi Alan,
Sorry, but I must join Russel here. I have atleast one machine which has
a bootloader able to load exactly one file only. There is currently no
way to load an initrd. It would need to implement the whole (BOOTP+)TFTP
stuff again, just to get the initrd. So I was quite happy linux 2.4
still knows about mounting a NFS root filesystem without user-space
help.
Just glue the initrd to the kernel. This is not rocket science
arch/sparc/boot/piggyback.c
Simple utility to make a single-image install kernel with initial ramdisk
for Sparc tftpbooting without need to set up nfs.
Copyright (C) 1996 Jakub Jelinek (jj@sunsite.mff.cuni.cz)
Pete Zaitcev [off-list ref] endian fixes for cross-compiles, 2000.
- Arnaldo