Re: [PATCH] mutliple root devs (take II)
On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote: > boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar > with (arch/um), that is usable from the beginning of start_kernel. I don't > know about the other arches. setup_arch does the necessary initialization on most architectures - you might want to consider fixing UML to be consistent with them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[EMAIL PROTECTED] said: > I was unsure if it was okay to be using kmalloc during early stages of > init/main.c so I decided to follow the example allready set and just > use a static array - can anyone advise on being able to do this > dynamically? kmalloc is usable after mem_init(), I think. Before that, you can use the boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar with (arch/um), that is usable from the beginning of start_kernel. I don't know about the other arches. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[Tracy Camp] > I was unsure if it was okay to be using kmalloc during early stages > of init/main.c so I decided to follow the example allready set and > just use a static array - can anyone advise on being able to do this > dynamically? Have a static 'char *' somewhere. In the "root=" callback function, just set this variable. Do not parse it until you are ready to actually mount root, then just parse one dev at a time. No allocation needed. Note that this approach doesn't support the "multiple root=" feature, which brings us to... > I guess I can't think of any really good reason why having multiple > root= is a necissary feature. Agreed, and there *is* good reason not to support this, since it is useful to be able to override a root= given in a config file. > Yeah you would need to patch lilo as well to handle the new syntax > amongst other things. Hmm. LILO shouldn't care, but it does, because it has a 'root=' parameter which it handles specially, by patching the 16-bit device number into the kernel image at runtime. Your patch should be fully functional, though, as long as people just use 'append="root=..."' instead of simply 'root=...'. The append= forces LILO not to treat the root dev specially. (This tip brought to you by the devfs docs.) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
> Hmmm, I don't like your array thing (also in v.I of the patch), > limiting us to possible root devices, where n==8. A better > approach might be to iterate over the root= arguments when mounting. I > know why you used the array -- easier to code. I was unsure if it was okay to be using kmalloc during early stages of init/main.c so I decided to follow the example allready set and just use a static array - can anyone advise on being able to do this dynamically? > One potential problem with the patch is that you have changed behavior > some people are relying on. If you use 'syslinux' to boot, for > example, the SYSLINUX.CFG file can define a default command line > including root=. Then you can augment that line at runtime by typing > in your own command line. Your patch makes it impossible, in this > situation, to override the default root device from the syslinux > command line. A kludge to make it work again would be to process the > root devices in reverse. That would be ugly and unintuitive, though. Yeah you would need to patch lilo as well to handle the new syntax amongst other things. I use grub and have no troubles along these lines. Refrencing the idea in the follow on message about just using the last root= only and not allowing multiple root= would work around this. I guess I can't think of any really good reason why having multiple root= is a necissary feature. t. Fear the future? Change the past. This message has resulted in an increase in the entropy of the universe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[I wrote] > Your patch makes it impossible, in this situation, to override the > default root device from the syslinux command line. A kludge to make > it work again would be to process the root devices in reverse. Better would be to reset the list of root devices with every 'root=' statement, rather than trying all of them as you do now. I.e. ... root=/dev/hda1 ... root=/dev/hda2,/dev/hda3 ... would *not* try hda1. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[Tracy Camp] > A much cleaner patch prompted after right proper chastisement on the > sloppy patch I sent a few days back. This one is against 2.4-pre11 Hmmm, I don't like your array thing (also in v.I of the patch), limiting us to possible root devices, where n==8. A better approach might be to iterate over the root= arguments when mounting. I know why you used the array -- easier to code. One potential problem with the patch is that you have changed behavior some people are relying on. If you use 'syslinux' to boot, for example, the SYSLINUX.CFG file can define a default command line including root=. Then you can augment that line at runtime by typing in your own command line. Your patch makes it impossible, in this situation, to override the default root device from the syslinux command line. A kludge to make it work again would be to process the root devices in reverse. That would be ugly and unintuitive, though. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
On Fri, 1 Dec 2000, T. Camp wrote: > Hmm didn't know that, from the user-land portable C perspective I'm in the > habit of zero'ing everything. - thanks. Yes, sorry, I should have explained a bit more, perhaps. The point is that when you have an unitialized variable like this: int x; the C compiler does not reserve any space for it in the final object file but rather puts special information in a section called BSS which tells how much stuff is there, so an appropriate memory image is created for that section during loading. Subsequently, the kernel initialisation code (see arch/i386/kernel/head.S, grep for BSS) explicitly initializes the content of that segment to 0 to comply with various ANSI C standards that demand this (which presumably demand this for the very reason of making such optimization possible). So, not initializing things explicitly saves space in the final disk image and is a common technique used (by far!) by the majority of Linux kernel code. In the past, I remember, some arguments against it such as 'having explicit 0 initialization better documents the code' but, of course, they are not valid because that is what we have /* */ for -- for documentation. Comments should not waste space or time. Anyway, I said too much on such trivial and obvious issue :) -- just making sure it is clear to you, that is all. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
On Fri, Dec 01, 2000 at 09:05:23AM -0800, T. Camp wrote: > Hmm didn't know that, from the user-land portable C perspective I'm in the > habit of zero'ing everything. - thanks. It's a requirement of the ISO C standard that all global/static (not local) variables are initialized to 0 is not initialized explicitely. It tends to be true, too. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
> indeed, much cleaner. But still not perfect. > > > + int root_device_index = 0; > > this initialisation is not needed. Just make it 'int root_device_index;' > The kernel will do the right thing for you on boot, trust me. > > > +int number_root_devs = 0; > > this is not needed either. Hmm didn't know that, from the user-land portable C perspective I'm in the habit of zero'ing everything. - thanks. t. Fear the future? Change the past. This message has resulted in an increase in the entropy of the universe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
Hello, On Fri, 1 Dec 2000, T. Camp wrote: > A much cleaner patch prompted after right proper chastisement on the indeed, much cleaner. But still not perfect. > + int root_device_index = 0; this initialisation is not needed. Just make it 'int root_device_index;' The kernel will do the right thing for you on boot, trust me. > +int number_root_devs = 0; this is not needed either. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mutliple root devs (take II)
A much cleaner patch prompted after right proper chastisement on the sloppy patch I sent a few days back. This one is against 2.4-pre11 but so far as I can tell should be good to go against any of the 2.4 series so far. I have not implemented a regex-like syntax as was suggested because 1) you can still do the same stuff just takes more typing 2) would make for a fairly large re-ordering of code afterall. basic idea here is that the kernel will search through a list of root devices passed to the kernel as arguements before giving up on the rootfs. ie. (from lilo:) linux root=/dev/hda1,/dev/hdc,/dev/hda7 will try each device in order. You can also split these up into separate root= statements just fine. please be sure to directly address me with any feedback as I'm not on the list. (I miss linux-kernel-digest). t. camp --snip-- diff --recursive --unified --ignore-all-space linux/Documentation/kernel-parameters.txt linux-2.4.0.11/Documentation/kernel-parameters.txt --- linux/Documentation/kernel-parameters.txt Tue Sep 5 13:51:14 2000 +++ linux-2.4.0.11/Documentation/kernel-parameters.txt Mon Nov 27 17:25:04 2000 @@ -473,7 +473,11 @@ ro [KNL] Mount root device read-only on boot. - root= [KNL] root filesystem. + root= [KNL] root filesystem, comma separated list of up +to eight /dev/ entries will be tried in order +presented until kernel suceeds in mounting a +filesystem, multiple independant 'root=' entries +allowed as well. rw [KNL] Mount root device read-write on boot. diff --recursive --unified --ignore-all-space linux/fs/super.c linux-2.4.0.11/fs/super.c --- linux/fs/super.cMon Oct 16 12:57:59 2000 +++ linux-2.4.0.11/fs/super.c Wed Nov 29 16:56:00 2000 @@ -18,6 +18,8 @@ *Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996. * Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998 * Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000 + * Modifications to mount_root for trying a list of root devices. + *Tracy Camp <[EMAIL PROTECTED]> 11/22/00 */ #include @@ -1470,6 +1472,7 @@ void *handle; char path[64]; int path_start = -1; + int root_device_index = 0; #ifdef CONFIG_ROOT_NFS void *data; @@ -1528,8 +1531,15 @@ } #endif - devfs_make_root (root_device_name); - handle = devfs_find_handle (NULL, ROOT_DEVICE_NAME, + for(root_device_index = 0; root_device_index < number_root_devs; +root_device_index++) { + printk("VFS: trying root on +%s\n",_device_name[root_device_index][0]); + if(root_device_name[root_device_index][0] != '\0') + { + ROOT_DEV = +name_to_kdev_t(_device_name[root_device_index][0]); /* translate */ + } + devfs_make_root (_device_name[root_device_index][0]); + handle = devfs_find_handle (NULL, + _device_name[root_device_index][0], MAJOR (ROOT_DEV), MINOR (ROOT_DEV), DEVFS_SPECIAL_BLK, 1); if (handle) /* Sigh: bd*() functions only paper over the cracks */ @@ -1566,10 +1576,10 @@ * and bad superblock on root device. */ printk ("VFS: Cannot open root device \"%s\" or %s\n", - root_device_name, kdevname (ROOT_DEV)); - printk ("Please append a correct \"root=\" boot option\n"); - panic("VFS: Unable to mount root fs on %s", + _device_name[root_device_index][0], kdevname (ROOT_DEV)); + printk("VFS: Unable to mount root fs on %s\n", kdevname(ROOT_DEV)); + continue; } check_disk_change(ROOT_DEV); @@ -1593,7 +1603,10 @@ put_filesystem(fs_type); } read_unlock(_systems_lock); - panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV)); + printk("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV)); + } /* end for */ + printk("VFS: Please append a corrent \"root=\" boot option\n"); + panic("VFS: Unable to mount any root fs at all"); mount_it: printk ("VFS: Mounted root (%s filesystem)%s.\n", @@ -1772,6 +1785,15 @@ } else path_release(_nd); } +/* this function seems to only be used when after an initrd usage, +* so the actual value of ROOT_DEV hasn't been determined until mount_root +* is called, because we try a list of root devices before giving up, +* this ROOT_DEV global is somewhat misleading now, as its only valid after +* a call to mount_root because mount_root ignores the ROOT_DEV value +*
[PATCH] mutliple root devs (take II)
A much cleaner patch prompted after right proper chastisement on the sloppy patch I sent a few days back. This one is against 2.4-pre11 but so far as I can tell should be good to go against any of the 2.4 series so far. I have not implemented a regex-like syntax as was suggested because 1) you can still do the same stuff just takes more typing 2) would make for a fairly large re-ordering of code afterall. basic idea here is that the kernel will search through a list of root devices passed to the kernel as arguements before giving up on the rootfs. ie. (from lilo:) linux root=/dev/hda1,/dev/hdc,/dev/hda7 will try each device in order. You can also split these up into separate root= statements just fine. please be sure to directly address me with any feedback as I'm not on the list. (I miss linux-kernel-digest). t. camp --snip-- diff --recursive --unified --ignore-all-space linux/Documentation/kernel-parameters.txt linux-2.4.0.11/Documentation/kernel-parameters.txt --- linux/Documentation/kernel-parameters.txt Tue Sep 5 13:51:14 2000 +++ linux-2.4.0.11/Documentation/kernel-parameters.txt Mon Nov 27 17:25:04 2000 @@ -473,7 +473,11 @@ ro [KNL] Mount root device read-only on boot. - root= [KNL] root filesystem. + root= [KNL] root filesystem, comma separated list of up +to eight /dev/ entries will be tried in order +presented until kernel suceeds in mounting a +filesystem, multiple independant 'root=' entries +allowed as well. rw [KNL] Mount root device read-write on boot. diff --recursive --unified --ignore-all-space linux/fs/super.c linux-2.4.0.11/fs/super.c --- linux/fs/super.cMon Oct 16 12:57:59 2000 +++ linux-2.4.0.11/fs/super.c Wed Nov 29 16:56:00 2000 @@ -18,6 +18,8 @@ *Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996. * Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998 * Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000 + * Modifications to mount_root for trying a list of root devices. + *Tracy Camp [EMAIL PROTECTED] 11/22/00 */ #include linux/config.h @@ -1470,6 +1472,7 @@ void *handle; char path[64]; int path_start = -1; + int root_device_index = 0; #ifdef CONFIG_ROOT_NFS void *data; @@ -1528,8 +1531,15 @@ } #endif - devfs_make_root (root_device_name); - handle = devfs_find_handle (NULL, ROOT_DEVICE_NAME, + for(root_device_index = 0; root_device_index number_root_devs; +root_device_index++) { + printk("VFS: trying root on +%s\n",root_device_name[root_device_index][0]); + if(root_device_name[root_device_index][0] != '\0') + { + ROOT_DEV = +name_to_kdev_t(root_device_name[root_device_index][0]); /* translate */ + } + devfs_make_root (root_device_name[root_device_index][0]); + handle = devfs_find_handle (NULL, + root_device_name[root_device_index][0], MAJOR (ROOT_DEV), MINOR (ROOT_DEV), DEVFS_SPECIAL_BLK, 1); if (handle) /* Sigh: bd*() functions only paper over the cracks */ @@ -1566,10 +1576,10 @@ * and bad superblock on root device. */ printk ("VFS: Cannot open root device \"%s\" or %s\n", - root_device_name, kdevname (ROOT_DEV)); - printk ("Please append a correct \"root=\" boot option\n"); - panic("VFS: Unable to mount root fs on %s", + root_device_name[root_device_index][0], kdevname (ROOT_DEV)); + printk("VFS: Unable to mount root fs on %s\n", kdevname(ROOT_DEV)); + continue; } check_disk_change(ROOT_DEV); @@ -1593,7 +1603,10 @@ put_filesystem(fs_type); } read_unlock(file_systems_lock); - panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV)); + printk("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV)); + } /* end for */ + printk("VFS: Please append a corrent \"root=\" boot option\n"); + panic("VFS: Unable to mount any root fs at all"); mount_it: printk ("VFS: Mounted root (%s filesystem)%s.\n", @@ -1772,6 +1785,15 @@ } else path_release(devfs_nd); } +/* this function seems to only be used when after an initrd usage, +* so the actual value of ROOT_DEV hasn't been determined until mount_root +* is called, because we try a list of root devices before giving up, +* this ROOT_DEV global is somewhat misleading now, as its only valid after +* a call to mount_root because
Re: [PATCH] mutliple root devs (take II)
Hello, On Fri, 1 Dec 2000, T. Camp wrote: A much cleaner patch prompted after right proper chastisement on the indeed, much cleaner. But still not perfect. + int root_device_index = 0; this initialisation is not needed. Just make it 'int root_device_index;' The kernel will do the right thing for you on boot, trust me. +int number_root_devs = 0; this is not needed either. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
indeed, much cleaner. But still not perfect. + int root_device_index = 0; this initialisation is not needed. Just make it 'int root_device_index;' The kernel will do the right thing for you on boot, trust me. +int number_root_devs = 0; this is not needed either. Hmm didn't know that, from the user-land portable C perspective I'm in the habit of zero'ing everything. - thanks. t. Fear the future? Change the past. This message has resulted in an increase in the entropy of the universe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
On Fri, 1 Dec 2000, T. Camp wrote: Hmm didn't know that, from the user-land portable C perspective I'm in the habit of zero'ing everything. - thanks. Yes, sorry, I should have explained a bit more, perhaps. The point is that when you have an unitialized variable like this: int x; the C compiler does not reserve any space for it in the final object file but rather puts special information in a section called BSS which tells how much stuff is there, so an appropriate memory image is created for that section during loading. Subsequently, the kernel initialisation code (see arch/i386/kernel/head.S, grep for BSS) explicitly initializes the content of that segment to 0 to comply with various ANSI C standards that demand this (which presumably demand this for the very reason of making such optimization possible). So, not initializing things explicitly saves space in the final disk image and is a common technique used (by far!) by the majority of Linux kernel code. In the past, I remember, some arguments against it such as 'having explicit 0 initialization better documents the code' but, of course, they are not valid because that is what we have /* */ for -- for documentation. Comments should not waste space or time. Anyway, I said too much on such trivial and obvious issue :) -- just making sure it is clear to you, that is all. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
On Fri, Dec 01, 2000 at 09:05:23AM -0800, T. Camp wrote: Hmm didn't know that, from the user-land portable C perspective I'm in the habit of zero'ing everything. - thanks. It's a requirement of the ISO C standard that all global/static (not local) variables are initialized to 0 is not initialized explicitely. It tends to be true, too. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[Tracy Camp] A much cleaner patch prompted after right proper chastisement on the sloppy patch I sent a few days back. This one is against 2.4-pre11 Hmmm, I don't like your array thing (also in v.I of the patch), limiting us to n possible root devices, where n==8. A better approach might be to iterate over the root= arguments when mounting. I know why you used the array -- easier to code. One potential problem with the patch is that you have changed behavior some people are relying on. If you use 'syslinux' to boot, for example, the SYSLINUX.CFG file can define a default command line including root=. Then you can augment that line at runtime by typing in your own command line. Your patch makes it impossible, in this situation, to override the default root device from the syslinux command line. A kludge to make it work again would be to process the root devices in reverse. That would be ugly and unintuitive, though. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[I wrote] Your patch makes it impossible, in this situation, to override the default root device from the syslinux command line. A kludge to make it work again would be to process the root devices in reverse. Better would be to reset the list of root devices with every 'root=' statement, rather than trying all of them as you do now. I.e. ... root=/dev/hda1 ... root=/dev/hda2,/dev/hda3 ... would *not* try hda1. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
Hmmm, I don't like your array thing (also in v.I of the patch), limiting us to n possible root devices, where n==8. A better approach might be to iterate over the root= arguments when mounting. I know why you used the array -- easier to code. I was unsure if it was okay to be using kmalloc during early stages of init/main.c so I decided to follow the example allready set and just use a static array - can anyone advise on being able to do this dynamically? One potential problem with the patch is that you have changed behavior some people are relying on. If you use 'syslinux' to boot, for example, the SYSLINUX.CFG file can define a default command line including root=. Then you can augment that line at runtime by typing in your own command line. Your patch makes it impossible, in this situation, to override the default root device from the syslinux command line. A kludge to make it work again would be to process the root devices in reverse. That would be ugly and unintuitive, though. Yeah you would need to patch lilo as well to handle the new syntax amongst other things. I use grub and have no troubles along these lines. Refrencing the idea in the follow on message about just using the last root= only and not allowing multiple root= would work around this. I guess I can't think of any really good reason why having multiple root= is a necissary feature. t. Fear the future? Change the past. This message has resulted in an increase in the entropy of the universe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
[Tracy Camp] I was unsure if it was okay to be using kmalloc during early stages of init/main.c so I decided to follow the example allready set and just use a static array - can anyone advise on being able to do this dynamically? Have a static 'char *' somewhere. In the "root=" callback function, just set this variable. Do not parse it until you are ready to actually mount root, then just parse one dev at a time. No allocation needed. Note that this approach doesn't support the "multiple root=" feature, which brings us to... I guess I can't think of any really good reason why having multiple root= is a necissary feature. Agreed, and there *is* good reason not to support this, since it is useful to be able to override a root= given in a config file. Yeah you would need to patch lilo as well to handle the new syntax amongst other things. Hmm. LILO shouldn't care, but it does, because it has a 'root=' parameter which it handles specially, by patching the 16-bit device number into the kernel image at runtime. Your patch should be fully functional, though, as long as people just use 'append="root=..."' instead of simply 'root=...'. The append= forces LILO not to treat the root dev specially. (This tip brought to you by the devfs docs.) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mutliple root devs (take II)
On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote: boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar with (arch/um), that is usable from the beginning of start_kernel. I don't know about the other arches. setup_arch does the necessary initialization on most architectures - you might want to consider fixing UML to be consistent with them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/