The patch at the end of this email makes ipconfig.c work as a loadable
module under the 2.5. The diff was taken against the bitkeeper tree
changeset 1.1075.
Currently ipconfig.o must get statically linked into the kernel. I have a
proprietary driver which the supplier will not provide a GPL version or
info. In order to mount root over NFS, I need to get the vendors driver
loaded via a ramdisk.
A couple more items get moved from ipconfig.h to nfs_fs.h.
Thanks,
Robin Holt
------------------------- Patch ---------------------------------------
===== fs/Kconfig 1.18 vs edited =====
--- 1.18/fs/Kconfig Sun Feb 9 19:29:49 2003
+++ edited/fs/Kconfig Wed Mar 5 11:07:56 2003
@@ -1270,7 +1270,7 @@
config ROOT_NFS
bool "Root file system on NFS"
- depends on NFS_FS=y && IP_PNP
+ depends on NFS_FS=y && IP_PNP!=n
help
If you want your Linux box to mount its whole root file system (the
one containing the directory /) from some other computer over the
===== fs/nfs/nfsroot.c 1.11 vs edited =====
--- 1.11/fs/nfs/nfsroot.c Thu Nov 7 11:29:59 2002
+++ edited/fs/nfs/nfsroot.c Wed Mar 5 11:07:56 2003
@@ -69,6 +69,7 @@
*/
#include <linux/config.h>
+#include <linux/module.h>
#include <linux/types.h>
#include <linux/string.h>
#include <linux/kernel.h>
@@ -106,6 +107,15 @@
static struct nfs_mount_data nfs_data __initdata = { 0, };/* NFS mount info */
static int nfs_port __initdata = 0; /* Port to connect to for NFS */
static int mount_port __initdata = 0; /* Mount daemon port number */
+
+
+u32 root_server_addr __initdata = INADDR_NONE; /* Address of NFS server */
+u8 root_server_path[NFS_ROOT_PATH_LEN] __initdata = { 0, }; /* Path to mount as root */
+
+#ifdef CONFIG_IP_PNP_MODULE
+EXPORT_SYMBOL(root_server_addr);
+EXPORT_SYMBOL(root_server_path);
+#endif
/***************************************************************************
===== include/linux/nfs_fs.h 1.43 vs edited =====
--- 1.43/include/linux/nfs_fs.h Sat Dec 21 00:29:02 2002
+++ edited/include/linux/nfs_fs.h Wed Mar 5 11:07:56 2003
@@ -417,7 +417,12 @@
/* NFS root */
+#ifdef CONFIG_ROOT_NFS
+#define NFS_ROOT_PATH_LEN 256
+extern u8 root_server_path[NFS_ROOT_PATH_LEN]; /* Path to mount as root */
+
extern void * nfs_root_data(void);
+#endif
#define nfs_wait_event(clnt, wq, condition) \
({ \
===== include/net/ipconfig.h 1.2 vs edited =====
--- 1.2/include/net/ipconfig.h Tue Feb 5 01:40:15 2002
+++ edited/include/net/ipconfig.h Wed Mar 5 11:07:56 2003
@@ -21,7 +21,6 @@
extern u32 ic_servaddr; /* Boot server IP address */
extern u32 root_server_addr; /* Address of NFS server */
-extern u8 root_server_path[]; /* Path to mount as root */
===== net/ipv4/Kconfig 1.4 vs edited =====
--- 1.4/net/ipv4/Kconfig Wed Nov 13 06:52:02 2002
+++ edited/net/ipv4/Kconfig Wed Mar 5 11:07:56 2003
@@ -133,8 +133,8 @@
you may want to say Y here to speed up the routing process.
config IP_PNP
- bool "IP: kernel level autoconfiguration"
- depends on INET
+ tristate "IP: kernel level autoconfiguration"
+ depends on INET!=n
help
This enables automatic configuration of IP addresses of devices and
of the routing table during kernel boot, based on either information
@@ -146,7 +146,7 @@
config IP_PNP_DHCP
bool "IP: DHCP support"
- depends on IP_PNP
+ depends on IP_PNP!=n
---help---
If you want your Linux box to mount its whole root file system (the
one containing the directory /) from some other computer over the
@@ -163,7 +163,7 @@
config IP_PNP_BOOTP
bool "IP: BOOTP support"
- depends on IP_PNP
+ depends on IP_PNP!=n
---help---
If you want your Linux box to mount its whole root file system (the
one containing the directory /) from some other computer over the
@@ -178,7 +178,7 @@
config IP_PNP_RARP
bool "IP: RARP support"
- depends on IP_PNP
+ depends on IP_PNP!=n
help
If you want your Linux box to mount its whole root file system (the
one containing the directory /) from some other computer over the
===== net/ipv4/ipconfig.c 1.22 vs edited =====
--- 1.22/net/ipv4/ipconfig.c Tue Feb 18 12:38:27 2003
+++ edited/net/ipv4/ipconfig.c Wed Mar 5 11:07:56 2003
@@ -32,6 +32,7 @@
*/
#include <linux/config.h>
+#include <linux/module.h>
#include <linux/types.h>
#include <linux/string.h>
#include <linux/kernel.h>
@@ -52,6 +53,7 @@
#include <linux/proc_fs.h>
#include <linux/major.h>
#include <linux/root_dev.h>
+#include <linux/nfs_fs.h>
#include <net/arp.h>
#include <net/ip.h>
#include <net/ipconfig.h>
@@ -131,9 +133,6 @@
u32 ic_servaddr __initdata = INADDR_NONE; /* Boot server IP address */
-u32 root_server_addr __initdata = INADDR_NONE; /* Address of NFS server */
-u8 root_server_path[256] __initdata = { 0, }; /* Path to mount as root */
-
/* Persistent data: */
int ic_proto_used; /* Protocol used, if any */
@@ -1136,6 +1135,7 @@
unsigned long jiff;
#ifdef CONFIG_PROC_FS
+ /* >>> Need to remove this on unload!!! */
proc_net_create("pnp", 0, pnp_get_info);
#endif /* CONFIG_PROC_FS */
@@ -1263,8 +1263,6 @@
return 0;
}
-module_init(ip_auto_config);
-
/*
* Decode any IP configuration options in the "ip=" or "nfsaddrs=" kernel
@@ -1386,6 +1384,29 @@
return 1;
}
+
+#ifdef CONFIG_IP_PNP_MODULE
+char *ip = NULL;
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Martin Mares");
+MODULE_DESCRIPTION("IP Autoconfig module: \n" \
+ "Uses BOOTP/DHCP/RARP to determine IP configuration before the root\n"
+ " filesystem is mounted. See nfsroot.txt in the kernel source.");
+MODULE_PARM(ip, "s");
+MODULE_PARM_DESC(ip, "[[<client-ip>]:[<server-ip>]:[<gw-ip>]:[<netmask>]:[<hostname>]:[<device>]:]<autoconf>");
+
+
+int __init init_module(void)
+{
+ if (ip != NULL) {
+ ip_auto_config_setup(ip);
+ }
+
+ return ip_auto_config();
+}
+#else
+module_init(ip_auto_config);
+
static int __init nfsaddrs_config_setup(char *addrs)
{
return ip_auto_config_setup(addrs);
@@ -1393,3 +1414,4 @@
__setup("ip=", ip_auto_config_setup);
__setup("nfsaddrs=", nfsaddrs_config_setup);
+#endif
On Thu, 2003-03-06 at 21:10, Robin Holt wrote:
> The patch at the end of this email makes ipconfig.c work as a loadable
> module under the 2.5. The diff was taken against the bitkeeper tree
> changeset 1.1075.
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.
Indeed probably the biggest distro using nfs root (LTSP) doesn't use ipconfig
even on 2.4.
DaveM can you just remove the thing. See http://www.ltsp.org for initrds that
don't need it in
On Thu, Mar 06, 2003 at 10:34:16PM +0000, Alan Cox wrote:
> On Thu, 2003-03-06 at 21:10, Robin Holt wrote:
> > The patch at the end of this email makes ipconfig.c work as a loadable
> > module under the 2.5. The diff was taken against the bitkeeper tree
> > changeset 1.1075.
>
> 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...
Jeff
On Thu, Mar 06, 2003 at 05:11:36PM -0500, Jeff Garzik wrote:
> On Thu, Mar 06, 2003 at 10:34:16PM +0000, Alan Cox wrote:
> > On Thu, 2003-03-06 at 21:10, Robin Holt wrote:
> > > The patch at the end of this email makes ipconfig.c work as a loadable
> > > module under the 2.5. The diff was taken against the bitkeeper tree
> > > changeset 1.1075.
> >
> > 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?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, Mar 06, 2003 at 10:25:46PM +0000, Russell King wrote:
> 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?
The klibc merge date appears to be infinity at this point.
Probably my fault, too.
Jeff
On Thu, 2003-03-06 at 22:25, Russell King wrote:
> > > 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
On Thu, 2003-03-06 at 23:19, Russell King wrote:
> "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 ?
On Fri, Mar 07, 2003 at 12:13:57AM +0000, Alan Cox wrote:
> On Thu, 2003-03-06 at 22:25, Russell King wrote:
> > > > 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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, Mar 07, 2003 at 12:29:47AM +0000, Alan Cox wrote:
> On Thu, 2003-03-06 at 23:19, Russell King wrote:
> > "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 ?
How about mount for nfs-root, a shell and a shell script to supply the
correct parameters to mount so it doesn't go and try to mount the
nfs-root with locking enabled - oh, and a few programs like sed and
so forth to pull the mount parameters out of the dhcp client output,
if there is such an output.
ipconfig.c does more than just configure networking. It's a far smaller
solution to NFS-root than any userspace implementation could ever hope
to be.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, Mar 07, 2003 at 12:08:16AM +0000, Russell King wrote:
> >
> > 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 ?
>
> How about mount for nfs-root, a shell and a shell script to supply the
> correct parameters to mount so it doesn't go and try to mount the
> nfs-root with locking enabled - oh, and a few programs like sed and
> so forth to pull the mount parameters out of the dhcp client output,
> if there is such an output.
If IBM can fit a kernel and a ramdisk containing all the utilities you
describe and more in smaller than 5M of file for tftp, one would think
that it could be done on Linux.
>
> ipconfig.c does more than just configure networking. It's a far smaller
> solution to NFS-root than any userspace implementation could ever hope
> to be.
That's nice. Would you mind explaining to us where that would be a
benefit? Aside from dead header space in elf executables, I'm at
a loss as to how a usermode implementation must be significantly
larger than kernel code.
--
Chris Dukes
I tried being reasonable once--I didn't like it.
Hi Alan,
you wrote:
> > 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
On 7 March 2003 02:29, Alan Cox wrote:
> On Thu, 2003-03-06 at 23:19, Russell King wrote:
> > "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, Mar 07, 2003 at 01:29:05AM +0000, Chris Dukes wrote:
> If IBM can fit a kernel and a ramdisk containing all the utilities you
> describe and more in smaller than 5M of file for tftp, one would think
> that it could be done on Linux.
Wow. 5MB eh? We currently do NFS-root in 690K.
> > ipconfig.c does more than just configure networking. It's a far smaller
> > solution to NFS-root than any userspace implementation could ever hope
> > to be.
>
> That's nice. Would you mind explaining to us where that would be a
> benefit? Aside from dead header space in elf executables, I'm at
> a loss as to how a usermode implementation must be significantly
> larger than kernel code.
If you're suggesting above that "5MB isn't significantly larger than
the size Linux can do this" then I think I've just proven you wrong.
Lets see - building an ramdisk to mount a root filesystem out of existing
binaries would require from my exisitng systems probably something like:
text data bss dec hex filename
1093047 21224 15560 1129831 113d67 /lib/libc.so.6
515890 22320 16640 554850 87762 /bin/sh
58540 2436 9776 70752 11460 /lib/libresolv.so.2
53685 1476 5488 60649 ece9 /bin/mount
45511 672 432 46615 b617 /bin/sed
42830 624 40 43494 a9e6 /sbin/pump
10783 500 104 11387 2c7b /lib/libtermcap.so.2
8765 444 28 9237 2415 /lib/libdl.so.2
pump isn't really suitable for the task, but I don't have dhcpcd around.
dhcpcd is even larger than pump however.
That's getting on for 2MB vs:
2620 2012 0 4632 1218 fs/nfs/nfsroot.o
8016 380 80 8476 211c net/ipv4/ipconfig.o
about 13K.
Which version is overly bloated?
Which version is huge?
Which version is compact?
Even the klibc ipconfig version is significantly larger than the in-kernel
version - and klibc and its binaries are written to be small.
Note: I *do* agree that ipconfig.c needs to die before 2.6 but I do not
agree that today is the right day.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
On Fri, 7 Mar 2003, Russell King wrote:
> Which version is overly bloated?
> Which version is huge?
> Which version is compact?
... and the size is not important only because we want to make everything
smaller, but because of how it's commonly used (at least in the clustering
world from which I come):
the mainboard BIOS or NIC PROC contains PXE/DHCP client; data is
transferred through UDP, with very poor (if any) congestion control.
Congestion control means here both extreme situations: if packets don't
arrive to the client, it might not ask again, ask only a limited number of
times or give up after some timeout; if the server has some faster NIC to
be able to handle more such requests, it might also send too fast for a
single client which might drop packets. In some cases, if such situation
occurs, the client just blocks there printing an error message on the
console, without trying to restart the whole process and the only way to
make it do something is to press the Reset button or plug in a keyboard...
When you have tens or hundreds of such nodes, it's not a pleasure !
Booting a bunch of such nodes would become problematic if they need
to transfer more data (=initrd) to start the kernel and so network booting
would become less reliable. Please note that I'm not saying "ipconfig has
to stay" - just that any solution should not dramatically increase the
size of data transferred before the jump to kernel code.
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: [email protected]
On Fri, Mar 07, 2003 at 09:42:35AM +0000, Russell King wrote:
> On Fri, Mar 07, 2003 at 01:29:05AM +0000, Chris Dukes wrote:
> > That's nice. Would you mind explaining to us where that would be a
> > benefit? Aside from dead header space in elf executables, I'm at
> > a loss as to how a usermode implementation must be significantly
> > larger than kernel code.
>
> If you're suggesting above that "5MB isn't significantly larger than
> the size Linux can do this" then I think I've just proven you wrong.
The 5Mb example is AIX.
>
> Lets see - building an ramdisk to mount a root filesystem out of existing
> binaries would require from my exisitng systems probably something like:
>
I said userspace. I did not say existing binaries.
[Size comparison of the kitchen sink vs kernel code deleted because
it's comparing apples and oranges].
>
> Which version is overly bloated?
> Which version is huge?
> Which version is compact?
You are asserting aesthetics instead of benefits. I asked about benefits.
Specifically, what is the benefit of compact?
I'm sure you have a very good technical or business benefit to compact,
but those of us in the world of workstations and servers have zero clue
what it may be.
Another individual has already indicated a very valid technical merit to
having it all in one file. I have the same problem myself. AIX and *BSD
have a working approach to that problem.
>
> Even the klibc ipconfig version is significantly larger than the in-kernel
> version - and klibc and its binaries are written to be small.
User space solution is not the same as a solution implemented with
multiple user space apps.
>
> Note: I *do* agree that ipconfig.c needs to die before 2.6 but I do not
> agree that today is the right day.
Perhaps you could explain why today is not the day.
(ie, soon to be shipping product that requires it. desire to see a viable
userspace solution working before it is removed).
--
Chris Dukes
I tried being reasonable once--I didn't like it.
On Fri, Mar 07, 2003 at 01:38:13PM +0000, Chris Dukes wrote:
> You are asserting aesthetics instead of benefits. I asked about benefits.
> Specifically, what is the benefit of compact?
Think _embedded_. Think "cost of flash chips". Think "not everything
has a floppy disk".
> I'm sure you have a very good technical or business benefit to compact,
I'm sorry, believe it or not, but I'm not swayed by "business benefits"
here. Although I have my own business in the UK, we as a business are
currently involved in hardware design which has nothing to do with the
points I'm raising here.
> but those of us in the world of workstations and servers have zero clue
> what it may be.
Indeed and understandable.
> User space solution is not the same as a solution implemented with
> multiple user space apps.
I've been working on klibc to work towards providing such a solution.
I know what it involves, and I know that this solution isn't there yet.
Also, the fundamentals of klibc have not been accepted by Linus, so we
don't even know if this is going to be a solution yet.
> > Note: I *do* agree that ipconfig.c needs to die before 2.6 but I do not
> > agree that today is the right day.
>
> Perhaps you could explain why today is not the day.
> (ie, soon to be shipping product that requires it. desire to see a viable
> userspace solution working before it is removed).
Just about every ARM kernel development downloads kernels via XMODEM
and the ability to bring networking up and mount a NFS-root filesystem
is by fair the easiest way to develop on *any* embedded device with
Ethernet.
I suppose you could say I have a _community_ interest here - an interest
in ensuring that the ARM community has the resources to be able to continue
using Linux.
So, while the big server people run around removing functionality they
don't need, they make other parts of the community suffer. Is that
really what Open Source is about? Suffering? 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Denis Vlasenko <[email protected]> wrote:
>
> Anything built static against glibs tends to be 400K+.
So don't use glibc. Link staticly against diet-libc or klibc.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[email protected]>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------
> > Anything built static against glibs tends to be 400K+.
>
> So don't use glibc. Link staticly against diet-libc or klibc.
Or newlib.
John.
On Fri, 7 Mar 2003, Russell King wrote:
> On Fri, Mar 07, 2003 at 01:38:13PM +0000, Chris Dukes wrote:
> > You are asserting aesthetics instead of benefits. I asked about benefits.
> > Specifically, what is the benefit of compact?
>
> Think _embedded_. Think "cost of flash chips". Think "not everything
> has a floppy disk".
>
> > I'm sure you have a very good technical or business benefit to compact,
>
> I'm sorry, believe it or not, but I'm not swayed by "business benefits"
> here. Although I have my own business in the UK, we as a business are
> currently involved in hardware design which has nothing to do with the
> points I'm raising here.
>
> > but those of us in the world of workstations and servers have zero clue
> > what it may be.
>
> Indeed and understandable.
>
> > User space solution is not the same as a solution implemented with
> > multiple user space apps.
>
> I've been working on klibc to work towards providing such a solution.
> I know what it involves, and I know that this solution isn't there yet.
> Also, the fundamentals of klibc have not been accepted by Linus, so we
> don't even know if this is going to be a solution yet.
>
> > > Note: I *do* agree that ipconfig.c needs to die before 2.6 but I do not
> > > agree that today is the right day.
> >
> > Perhaps you could explain why today is not the day.
> > (ie, soon to be shipping product that requires it. desire to see a viable
> > userspace solution working before it is removed).
>
> Just about every ARM kernel development downloads kernels via XMODEM
> and the ability to bring networking up and mount a NFS-root filesystem
> is by fair the easiest way to develop on *any* embedded device with
> Ethernet.
>
> I suppose you could say I have a _community_ interest here - an interest
> in ensuring that the ARM community has the resources to be able to continue
> using Linux.
>
> So, while the big server people run around removing functionality they
> don't need, they make other parts of the community suffer. Is that
> really what Open Source is about? Suffering? 8)
>
> --
> Russell King ([email protected]) The developer of ARM Linux
> http://www.arm.linux.org.uk/personal/aboutme.html
> -
As the kernel changes there are some things that really need to remain.
You need to be able to boot from a "floppy" disk. Yes, now-days it's
probably not a real floppy, but a BIOS module that emulates a floppy.
A lot of people don't realilize that this is how a CD/ROM is booted!
The BIOS configures it to "look" like a floppy for the purpose of
booting. A "bootable" CD/ROM has as its first partition, the image
of a floppy disk.
Also, many embeded systems boot from a "RAM" disk that emulates
a floppy disk for the purpose of booting. In fact, there is
a good argument to make virtually all embeded systems that
use the same CPU as the development environment, boot this way.
You can design, code, and test the whole damn thing while the
hardware engineers are still laying out components. One such
RAM disk on our equipment, pages in "sectors" through a tiny
(0x1000) window which disappears after booting, therefore no
address-space is given up to some NVRAM. Linux is unmodified,
thinking it was booted from a 1.44 MB floppy.
If the kernel grows to where this can't be done anymore, then
embeded systems will not use modern kernels. It's that simple.
So, increased functionality really needs to be put into modules
so that the basic kernel doesn't continue to increase in size.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Hi Alan,
you wrote:
> > 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
On Fri, Mar 07, 2003 at 09:42:35AM +0000, Russell King wrote:
> That's getting on for 2MB vs:
> 2620 2012 0 4632 1218 fs/nfs/nfsroot.o
> 8016 380 80 8476 211c net/ipv4/ipconfig.o
> about 13K.
There's a cap on the maximum size of things various bootloaders can
load via tftp; 2MB is relatively certain to blow it. ISTR the limit
being something near 1MB for 2 of my boxen.
-- wli
William Lee Irwin III wrote:
> On Fri, Mar 07, 2003 at 09:42:35AM +0000, Russell King wrote:
>
>>That's getting on for 2MB vs:
>> 2620 2012 0 4632 1218 fs/nfs/nfsroot.o
>> 8016 380 80 8476 211c net/ipv4/ipconfig.o
>>about 13K.
>>
>
> There's a cap on the maximum size of things various bootloaders can
> load via tftp; 2MB is relatively certain to blow it. ISTR the limit
> being something near 1MB for 2 of my boxen.
Since this is totally machine/architecture specific (we're tftp'ing 10MB
kernel/ramdisk images to embedded PPC machines here) it might be a good
idea to ask around and find what the most restrictive requirements are.
Is 1MB the worst-case or does it get even tighter?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Bogdan Costescu <[email protected]> writes:
> On Fri, 7 Mar 2003, Russell King wrote:
>
> > Which version is overly bloated?
> > Which version is huge?
> > Which version is compact?
>
> ... and the size is not important only because we want to make everything
> smaller, but because of how it's commonly used (at least in the clustering
> world from which I come):
>
> the mainboard BIOS or NIC PROC contains PXE/DHCP client; data is
> transferred through UDP, with very poor (if any) congestion control.
Only because the implementations suck. See etherboot.
> Congestion control means here both extreme situations: if packets don't
> arrive to the client, it might not ask again, ask only a limited number of
> times or give up after some timeout; if the server has some faster NIC to
> be able to handle more such requests, it might also send too fast for a
> single client which might drop packets. In some cases, if such situation
> occurs, the client just blocks there printing an error message on the
> console, without trying to restart the whole process and the only way to
> make it do something is to press the Reset button or plug in a keyboard...
> When you have tens or hundreds of such nodes, it's not a pleasure !
But this is all before the kernel is loaded. Having booted a 1000 node
cluster with TFTP and DHCP. From a single host with even being in the same
town, I think I have some room to talk.
> Booting a bunch of such nodes would become problematic if they need
> to transfer more data (=initrd) to start the kernel and so network booting
> would become less reliable. Please note that I'm not saying "ipconfig has
> to stay" - just that any solution should not dramatically increase the
> size of data transferred before the jump to kernel code.
Right. But I would suggest fixing your NBP (what PXE load) which must
be < 64K anyway if you have noticeable reliability problems. Not that
I even suggest using PXE for production use anyway. But sometimes
you are stuck with what you can do.
Eric
Bogdan Costescu <[email protected]> writes:
> On 7 Mar 2003, Eric W. Biederman wrote:
>
> > Only because the implementations suck. See etherboot.
>
> Agreed, but as you rightly say at the end of your message...
>
> > But sometimes you are stuck with what you can do.
>
> ... and you can't go use etherboot or whatever, you have to deal with it.
At the very least I can use etherboot as a NBP in PXE terms. So I have
a reasonable client after the first tftp transaction.
> You can deal with it today because ipconfig is small, you might not be
> able to deal with it tomorrow if you'll have to transfer twice as much
> because of a big initrd.
I routinely support an initrd with:
glibc.
/bin/bash
dhclient
mke2fs
mkreiserfs
parted
sfdisk
mount
pivot_root
etc. (All binaries were striped though).
And I usually have to pass an ramdisk_size=XXX option to the kernel or
my decompressed initial ramdisk is to large. I use it for setting up
a local filesystem on a cluster node. And I was able to setup an
entire cluster 1000 node cluster in about 15-20 minutes. (Multicast cuts
down on the bandwidth requirements which is very nice).
With a good bootloader it does not much how big your initrd is. I
totally agree that small is good and important. At the same time
ipconfig.c is wrong. It is great during development and on systems
with a single NIC. But the hard coded policies can be bad for
production systems. Not that hard coded policies are bad in general
just the kernel is the wrong place to put them.
> > But this is all before the kernel is loaded.
>
> But that's exactly my point. The ipconfig functionality is needed and what
> I ask for is that whatever means (if any) are chosen to replace it, they
> should keep the low size.
Similar functionality is definitely needed.
>
> > Having booted a 1000 node cluster with TFTP and DHCP.
>
> I do not doubt this, but I'm afraid that you (or we) might not be able to
> do it again tomorrow. And probably this is an ideal case where you have
> used the better solution as client (etherboot)...
True. But when things are important and the there is GPL'd firmware
available that actually works properly. It is worth putting it on the
requirements list of things to do.
Eric
On Sat, Mar 08, 2003 at 09:07:11AM -0700, Eric W. Biederman wrote:
> With a good bootloader it does not much how big your initrd is. I
> totally agree that small is good and important. At the same time
> ipconfig.c is wrong. It is great during development and on systems
> with a single NIC. But the hard coded policies can be bad for
> production systems. Not that hard coded policies are bad in general
> just the kernel is the wrong place to put them.
With multi-NIC systems, it is perfectly possible to use ipconfig.c with
one specific interface.
/*
* Decode any IP configuration options in the "ip=" or "nfsaddrs=" kernel
* command line parameter. It consists of option fields separated by colons in
* the following order:
*
* <client-ip>:<server-ip>:<gw-ip>:<netmask>:<host name>:<device>:<PROTO>
*
* Any of the fields can be empty which means to use a default value:
* <client-ip> - address given by BOOTP or RARP
* <server-ip> - address of host returning BOOTP or RARP packet
* <gw-ip> - none, or the address returned by BOOTP
* <netmask> - automatically determined from <client-ip>, or the
* one returned by BOOTP
* <host name> - <client-ip> in ASCII notation, or the name returned
* by BOOTP
* <device> - use all available devices
* <PROTO>:
* off|none - don't do autoconfig at all (DEFAULT)
* on|any - use any configured protocol
* dhcp|bootp|rarp - use only the specified protocol
* both - use both BOOTP and RARP (not DHCP)
*/
ip=:::::eth0:dhcp
(I haven't actually tried this though.)
However, how do you configure your ramdisk via the boot loader to use
a specific NIC / mount a specific filesystem, etc?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King <[email protected]> writes:
> On Sat, Mar 08, 2003 at 09:07:11AM -0700, Eric W. Biederman wrote:
> > With a good bootloader it does not much how big your initrd is. I
> > totally agree that small is good and important. At the same time
> > ipconfig.c is wrong. It is great during development and on systems
> > with a single NIC. But the hard coded policies can be bad for
> > production systems. Not that hard coded policies are bad in general
> > just the kernel is the wrong place to put them.
>
> With multi-NIC systems, it is perfectly possible to use ipconfig.c with
> one specific interface.
Sorry. I expressed that wrong. It is not multi-NIC that ipconfig.c gets
wrong. It is multiple DHCP servers. You just get multiple dhcp
servers when you have multiple NICs.
The policies in ipconfig.c are quite good, they just are not
universally applicable. But as ipconfig.c is in the kernel it tends
to get used where it is inappropriate.
> ip=:::::eth0:dhcp
>
> (I haven't actually tried this though.)
I had forgotten about that one, and I believe it helps in some cases.
> However, how do you configure your ramdisk via the boot loader to use
> a specific NIC / mount a specific filesystem, etc?
I can change the contents of my ramdisk as easily as I can change
the kernel command line. For the complex setups just placing
a configuration file in the ramdisk is what seems to work the best
in practice.
Eric
On Sat, Mar 08, 2003 at 09:48:16AM -0700, Eric W. Biederman wrote:
> I can change the contents of my ramdisk as easily as I can change
> the kernel command line. For the complex setups just placing
> a configuration file in the ramdisk is what seems to work the best
> in practice.
You'll forgive me if I don't think that "change the contents of ramdisk"
is as easy as changing the kernel command line.
Last time I checked, to change the contents of a ramdisk image, you needed
to ungzip it, mount it, make some changes, unmount it, re-gzip it, and
re-install the thing. Or, in the case of initramfs, you need to rebuild
the kernel image. Compare this to changing the kernel command line from
"root=/dev/hda1" to "root=/dev/nfs ip=dhcp" in the boot loader by hitting
a few keys on the keyboard before the kernel loads, and I think you'll
start to get my point here.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King <[email protected]> writes:
> On Sat, Mar 08, 2003 at 09:48:16AM -0700, Eric W. Biederman wrote:
> > I can change the contents of my ramdisk as easily as I can change
> > the kernel command line. For the complex setups just placing
> > a configuration file in the ramdisk is what seems to work the best
> > in practice.
>
> You'll forgive me if I don't think that "change the contents of ramdisk"
> is as easy as changing the kernel command line.
>
> Last time I checked, to change the contents of a ramdisk image, you needed
> to ungzip it, mount it, make some changes, unmount it, re-gzip it, and
> re-install the thing. Or, in the case of initramfs, you need to rebuild
> the kernel image. Compare this to changing the kernel command line from
> "root=/dev/hda1" to "root=/dev/nfs ip=dhcp" in the boot loader by hitting
> a few keys on the keyboard before the kernel loads, and I think you'll
> start to get my point here.
Currently on systems I am talking I have a directory structured like:
dir/config
dir/bzImage
dir/ramdisk
dir/ramdisk/sbin/init
dir/ramdisk/etc/
.....
So I edit dir/ramdisk/etc/somefile.conf and run a script that rebuilds
everything. Or I edit dir/config which has my command line in it
and run the script again.
Getting to this point took a bit of effort but that is where I am
at now.
With initramfs it becomes as designed it becomes easier because it easier
to build a cpio archive. But mkcramfs has similar properties for
building filesystems. The whole building the initramfs thing into
the kernel is something that probably needs to be worked so the
initramfs can be attached to the kernel separately. When the bootable
kernel image is ELF that is easy. With something like bzImage on x86
it can be a pain, as there isn't any room to extend the things.
And all I asserted is that for ``me'' it is equally simple to change
the ramdisk contents as to changes those of a file.
For something like /bin/kinit that contains the default kernel
polices on how to mount root it should certainly be command line
driven.
For complicated setups where I am partitioning the hard drives,
making filesystems, and installing over the network. A configuration
file has proven to be easier, and that is what I do. The fundamental
issue is that after a certain point the command line just does not
have room for all of the parameters needed.
Possibly I answered the wrong question?
As for hitting a few keys on the keyboard in the bootloader before
the kernel loads well.... That is good on one machine, it gets to be
a pain on 4. And at a 1000 I have much better things to do with my
time. Which just shows my bias from working on with clusters. On a
cluster the only time you want to treat a machine as an individual is
when you are replacing bad hardware.
I have played with parsing command line options. And messing
with /proc/cmdline or being /sbin/init and just getting those options
from the kernel is not difficult. For prototyping it may be a good
idea to read /proc/cmdline so the kernel can eat the options before
kinit does.
Eric
"Richard B. Johnson" <[email protected]> said:
[...]
> As the kernel changes there are some things that really need to remain.
> You need to be able to boot from a "floppy" disk.
No...
> Yes, now-days it's
> probably not a real floppy, but a BIOS module that emulates a floppy.
> A lot of people don't realilize that this is how a CD/ROM is booted!
Red Hat 8.0 boots directly from the ISO filesystem, IIUC. Plus "floppy
booting" mostly means using FreeDOS + syslinux, or even an ext2 floppy with
lilo or grub. The "floppy booting" discussed here is doing:
dd if=bzImage of=/dev/fd0
and booting that floppy directly. I really don't remember when I did that
last time, it must have been at least 5 years ago.
Embedded systems I've seen do strange shenanigans with custom bootloaders
to get the kernel into RAM, no floppy involved.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Em Fri, Mar 07, 2003 at 12:54:36PM +0000, Alan Cox escreveu:
> 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
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 ([email protected])
Pete Zaitcev <[email protected]> endian fixes for cross-compiles, 2000.
- Arnaldo
On Sat, Mar 08, 2003 at 10:21:13PM -0300, Horst von Brand wrote:
> The "floppy booting" discussed here is doing:
>
> dd if=bzImage of=/dev/fd0
>
> and booting that floppy directly. I really don't remember when I did that
> last time, it must have been at least 5 years ago.
I do use it frequently. I frequently boot systems using PXE, but sometimes,
either the bios is buggy, or I don't find how to set it up correctly, so the
better, and most reliable solution is to insert a floppy containing the kernel
which would have been loaded from the PXE server.
In fact, NONE of my systems need nor use an initrd. I find it really useful
to be able to boot from one single file. Having to set up an initrd is really
a pain compared to other trivial solutions. I'd really like Linux not to become
like microsoft products : it's not because one developper doesn't have the need
for something that he must prevent all his users/customers from using it.
I think that there are several people here who think they need ipconfig, and
that should be enough to understand that it's a useful feature, even if you
don't need it yourself.
Regards,
Willy