[PATCH] ip autoconfig with modules, kernel 2.4

[PATCH] ip autoconfig with modules, kernel 2.4

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Please CC me on any responses as I don't read the kernel-list in my
inbox.  Thanx.

I am looking for comments on the attached patch.  It's purpose is to
allow IP AutoConfig to happen additionally after the loading of an
initial ramdisk.

This allows one to use a "generic all-purpose" built kernel (i.e. a
fully modular kernel) to retrieve it's IP configuration via BOOTP or
RARP (and DHCP when that is ported into 2.4) as long as the ethernet
driver module for the installed ethernet card is loaded via the
initial ramdisk.

Of course, this elminates the need to build kernels with lots of
statically linked ethernet drivers or building lots of kernels with
specific drivers statically linked in.

My hope is that this is seen as a good idea (and a good
implementation) and that the patch is accepted into the Linux kernel.

All comments welcome.

Thanx,
b.


[-- Attachment #2: Patch for ipautoconfig with ethernet modules --]
[-- Type: text/plain, Size: 875 bytes --]

--- linux-2.2.17.old/init/main.c.orig	Tue Mar 27 15:59:08 2001
+++ linux-2.2.17/init/main.c	Tue Mar 27 16:01:03 2001
@@ -132,6 +132,10 @@
 kdev_t real_root_dev;
 #endif
 
+#if CONFIG_IP_PNP
+extern int __init ip_auto_config(void);
+#endif
+
 int root_mountflags = MS_RDONLY;
 char *execute_command;
 
@@ -863,6 +863,9 @@
 			while (pid != wait(&i));
 		if (MAJOR(real_root_dev) != RAMDISK_MAJOR
 		     || MINOR(real_root_dev) != 0) {
+#if CONFIG_IP_PNP
+			ip_auto_config();
+#endif
 			error = change_root(real_root_dev,"/initrd");
 			if (error)
 				printk(KERN_ERR "Change root to /initrd: "
--- linux/net/ipv4/ipconfig.c	Wed May  9 00:05:43 2001
+++ linux/net/ipv4/ipconfig.c.new	Wed May  9 00:05:41 2001
@@ -823,7 +823,7 @@
  *	IP Autoconfig dispatcher.
  */
 
-static int __init ip_auto_config(void)
+int __init ip_auto_config(void)
 {
 	if (!ic_enable)
 		return 0;

Re: [PATCH] ip autoconfig with modules, kernel 2.4

[Russell King]

On Thu, May 10, 2001 at 09:49:53AM -0700, Brian J. Murrell wrote:
> Of course, this elminates the need to build kernels with lots of
> statically linked ethernet drivers or building lots of kernels with
> specific drivers statically linked in.
> 
> My hope is that this is seen as a good idea (and a good
> implementation) and that the patch is accepted into the Linux kernel.

Hmm, if you've got userspace up and running, and loaded kernel
modules using insmod, then what's wrong about running a dhcp,
bootp or rarp client from userspace?  You can then drop the
kernel space IP autoconfiguration code.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] ip autoconfig with modules, kernel 2.4

[Brian J. Murrell]

On Thu, May 10, 2001 at 06:00:39PM +0100, Russell King wrote:
> 
> Hmm, if you've got userspace up and running, and loaded kernel
> modules using insmod, then what's wrong about running a dhcp,
> bootp or rarp client from userspace?

In theory, and for just ip configuration, nothing.

I should have given more information though.  My goal is actually to
NFSRoot the machine being booted.  I could not determine a way to get
the "root path" attribute given by the dhcp/bootp server from
userspace back to the kernel so that it can
"change_root()/mount_root()" with it.  I seem to recall there was a
proc interface for doing this at one time (in the 2.2 kernel) but it
seemed to have went away.

> You can then drop the
> kernel space IP autoconfiguration code.

If there were a way to tell the kernel, from userspace, for
change_root()/mount_root() where the nfsroot path was, yes.  I have
been hunting through all of the (nfs) root mount code and I don't see
it.  It looks like it can be set either on the command line, or by the
kernel implementation of bootp.  Am I missing it somewhere?

b.

Re: [PATCH] ip autoconfig with modules, kernel 2.4

[Peter Svensson]

On Fri, 11 May 2001, Brian J. Murrell wrote:

> If there were a way to tell the kernel, from userspace, for
> change_root()/mount_root() where the nfsroot path was, yes.  I have
> been hunting through all of the (nfs) root mount code and I don't see
> it.  It looks like it can be set either on the command line, or by the
> kernel implementation of bootp.  Am I missing it somewhere?

Doesn't the pivot_root do just that in 2.4? Not that I have used it or
anything.

Peter
--
Peter Svensson      ! Pgp key available by finger, fingerprint:
<petersv@psv.nu>    ! 8A E9 20 98 C1 FF 43 E3  07 FD B9 0A 80 72 70 AF
<petersv@df.lth.se> !
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...

Re: [PATCH] ip autoconfig with modules, kernel 2.4

[Russell King]

On Fri, May 11, 2001 at 11:13:00AM -0700, Brian J. Murrell wrote:
> I should have given more information though.  My goal is actually to
> NFSRoot the machine being booted.  I could not determine a way to get
> the "root path" attribute given by the dhcp/bootp server from
> userspace back to the kernel so that it can
> "change_root()/mount_root()" with it.  I seem to recall there was a
> proc interface for doing this at one time (in the 2.2 kernel) but it
> seemed to have went away.

As long as you can get the root server IP and path from the DHCP client,
then you mount it in a directory, and use pivot_root() to change to
that directory.

See the "Changing the root device" of Documentation/initrd.txt for more
information about this.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] ip autoconfig with modules, kernel 2.4

[Brian J. Murrell]

On Fri, May 11, 2001 at 07:38:33PM +0100, Russell King wrote:
> 
> As long as you can get the root server IP and path from the DHCP client,

I can do that.  :-)

> then you mount it in a directory, and use pivot_root() to change to
> that directory.

Cool.

> See the "Changing the root device" of Documentation/initrd.txt for more
> information about this.

This looks like the ticket.  I will hack away at that when I can get a
moment.  :-)

Thanx!

b.