Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

[Raz Ben Yehuda]

From: Raz ben yehuda <rbenyehuda@manz.com>

Patch is aimed to bypass the need for initramfs when it is not
known which disk has the root file system.

Example: The kernel boot parameter "root=/dev/sda1,/dev/sdc1,/dev/sdb4".
Check if /dev/sda1 exists ,if /dev/sda1 does not exist then try
/dev/sdc1 an so on upto the first a device that exists ( ROOT_DEV != 0 ), 
else use the last device as the mount device.

Signed-off-by: Raz Ben Yehuda <rbenyehuda@manz.com>

---

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 0f6e1d9..02ed235 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -162,9 +162,10 @@ done:
  *         of partition - device number of disk plus the partition number
  *	5) /dev/<disk_name>p<decimal> - same as the above, that form is
  *	   used when disk name of partitioned disk ends on a digit.
- *	6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
+ *	6) /dev/<disk name><decimal>,/dev/<disk name><decimal>,...
+ *	7) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
  *	   unique id of a partition if the partition table provides it.
- *	7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
+ *	8) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
  *	   a partition with a known unique id.
  *
  *	If name doesn't have fall into the categories above, we return (0,0).
@@ -469,6 +470,63 @@ void __init mount_root(void)
 #endif
 }
 
+void scan_root_dev_list(void)
+{
+	char *root_device_eol;
+	char *tmp_dev_name = saved_root_name;
+	char *comma;
+
+	comma = root_device_name;
+	root_device_eol = root_device_name + strlen(root_device_name);
+
+	for (; comma != root_device_eol ;) {
+		char dev_name[64];
+		/*
+		 * scan for active device from
+		 * root=/dev/sda1,/dev/sda2,...
+		*/
+		comma = strchr(tmp_dev_name, ',');
+		if (!comma) {
+			/*
+			 * if there is no list of devices
+			 * ( root=/dev/sdaX) or we are at the end
+			*/
+			root_device_name = tmp_dev_name;
+			ROOT_DEV = name_to_dev_t(root_device_name);
+			printk(KERN_INFO "trying device %s\n",
+				root_device_name);
+			break;
+		}
+		/*
+		 * ok, we failed with first device,
+		 * move to next one in the comma separated list
+		 */
+		memset(dev_name, 0, sizeof(dev_name));
+		strncpy(dev_name, tmp_dev_name,
+					(long)comma - (long)tmp_dev_name);
+		ROOT_DEV = name_to_dev_t(dev_name);
+		printk(KERN_INFO "trying device %s\n", dev_name);
+		if (ROOT_DEV == 0) {
+			tmp_dev_name = comma + 1;
+			if (tmp_dev_name < root_device_eol)
+				continue;
+			break;
+		}
+		/*
+		 * we're lucky, we have a device,
+		 * let set root_device_name to point at it
+		*/
+		strcpy(root_device_name, dev_name);
+		break;
+	}
+	if (ROOT_DEV == 0) {
+		printk(KERN_INFO "kernel is likely to panic aiee..\n");
+		return;
+	}
+	printk(KERN_INFO "Found %s appropriate for boot\n",
+		root_device_name);
+}
+
 /*
  * Prepare the namespace - decide what/where to mount, load ramdisks, etc.
  */
@@ -500,10 +558,10 @@ void __init prepare_namespace(void)
 			mount_block_root(root_device_name, root_mountflags);
 			goto out;
 		}
-		ROOT_DEV = name_to_dev_t(root_device_name);
-		if (strncmp(root_device_name, "/dev/", 5) == 0)
-			root_device_name += 5;
+		scan_root_dev_list();
 	}
+	if (strncmp(root_device_name, "/dev/", 5) == 0)
+			root_device_name += 5;
 
 	if (initrd_load())
 		goto out;

Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

[Raz Ben Yehuda]

On Thu, 2011-12-15 at 16:02 +0100, H. Peter Anvin wrote:
> On 12/15/2011 01:13 AM, Raz Ben Yehuda wrote:
> > From: Raz ben yehuda<rbenyehuda@manz.com>
> >
> > Patch is aimed to bypass the need for initramfs when it is not
> > known which disk has the root file system.
> >
> > Example: The kernel boot parameter "root=/dev/sda1,/dev/sdc1,/dev/sdb4".
> > Check if /dev/sda1 exists ,if /dev/sda1 does not exist then try
> > /dev/sdc1 an so on upto the first a device that exists ( ROOT_DEV != 0 ),
> > else use the last device as the mount device.
> >
> > patch is on top of 3.2-rc5.
> >
> > Signed-off-by: Raz Ben Yehuda<rbenyehuda@manz.com>
> >
> 
> To which point I have to ask, once again, at which point we stop putting 
> this stuff in the kernel to "bypass the need for initramfs"...
because there are times where we cannot use initramfs. is this a problem
with way i phrase or with with the whole idea ?  

> 	-hpa

Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

[H. Peter Anvin]

On 12/15/2011 07:19 AM, Raz Ben Yehuda wrote:
>>
>> To which point I have to ask, once again, at which point we stop putting
>> this stuff in the kernel to "bypass the need for initramfs"...
> because there are times where we cannot use initramfs. is this a problem
> with way i phrase or with with the whole idea ?
>

There are problems with the whole concept of "cannot use initramfs".  We 
allow the initramfs to be integrated with the kernel image for a reason, 
for example.

I'm obviously ranting on this in part to make people think about what 
they are doing, and partly to remind that the more complex the in-kernel 
root-mounting code get, the more it might be worth reconsidering klibc 
in the kernel build tree.

	-hpa

Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

[Kay Sievers]

On Thu, Dec 15, 2011 at 16:22, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/15/2011 07:19 AM, Raz Ben Yehuda wrote:
>>>
>>> To which point I have to ask, once again, at which point we stop putting
>>> this stuff in the kernel to "bypass the need for initramfs"...
>>
>> because there are times where we cannot use initramfs. is this a problem
>> with way i phrase or with with the whole idea ?

I don't see why stuff needs to search a hard-coded list of stuff. That
logic seems pretty much backwards to me. You either use the GPT stuff
that allows to flag the right partition to boot from a set of
partitions, or you go as far as make the kernel parse the filesystem
UUID of partitions. But hard-coding search lists on the commandline, I
really don't understand.

> There are problems with the whole concept of "cannot use initramfs".  We
> allow the initramfs to be integrated with the kernel image for a reason, for
> example.
>
> I'm obviously ranting on this in part to make people think about what they
> are doing, and partly to remind that the more complex the in-kernel
> root-mounting code get, the more it might be worth reconsidering klibc in
> the kernel build tree.

I think the whole picture of klibc is confusing and I very much don't
want to see that busybox-style hacking in the kernel sources.

Distros can not afford to support 2 libcs at bootup, and the distro
initramfss gets so complicated today, that a klibc-only solution does
not really work. So we end up with 2 libcs in the same initramfs
image, which makes zero sense. Leave alone the fact, that the klibc
tools duplicate all the stuff that already works in the real root in a
completely different and mostly insufficient and sometimes scary way.

The thing is, if the setup is that simple that klibc works, it is very
likely that the current in-kernel mount code is simple, well tested
and sufficient enough. If a distro-style intramfs is needed, klibc is
not usable (see above). The big distros will very unlikely ever pick
it up. The the remaining use-cases will stay a niche, that, I think,
does not justify the kernel inclusion of klibc.

If the whole klibc approach, if not entirely rethought, I doubt it
will ever go anywhere. In my opinion, with all what I've seen the last
years, we either work on a full libc in the kernel tree, that can be
used by normal userspace too, or we leave the tiny stuff to busybox
and one of the existing tiny libcs.

Kay

Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

[Raz Ben Yehuda]

On Thu, 2011-12-15 at 19:11 +0100, Kay Sievers wrote:
> On Thu, Dec 15, 2011 at 16:22, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 12/15/2011 07:19 AM, Raz Ben Yehuda wrote:
> >>>
> >>> To which point I have to ask, once again, at which point we stop putting
> >>> this stuff in the kernel to "bypass the need for initramfs"...
> >>
> >> because there are times where we cannot use initramfs. is this a problem
> >> with way i phrase or with with the whole idea ?
> 
> I don't see why stuff needs to search a hard-coded list of stuff. That
> logic seems pretty much backwards to me. You either use the GPT stuff
> that allows to flag the right partition to boot from a set of
> partitions, or you go as far as make the kernel parse the filesystem
> UUID of partitions. But hard-coding search lists on the commandline, I
> really don't understand.
Will GPT or fs UUID parsing solve the problem of having the kernel
think that hda has the root filesystem while hdc has it ?
> > There are problems with the whole concept of "cannot use initramfs".  We
> > allow the initramfs to be integrated with the kernel image for a reason, for
> > example.
> >
> > I'm obviously ranting on this in part to make people think about what they
> > are doing, and partly to remind that the more complex the in-kernel
> > root-mounting code get, the more it might be worth reconsidering klibc in
> > the kernel build tree.
> 
> I think the whole picture of klibc is confusing and I very much don't
> want to see that busybox-style hacking in the kernel sources.
> 
> Distros can not afford to support 2 libcs at bootup, and the distro
> initramfss gets so complicated today, that a klibc-only solution does
> not really work. So we end up with 2 libcs in the same initramfs
> image, which makes zero sense. Leave alone the fact, that the klibc
> tools duplicate all the stuff that already works in the real root in a
> completely different and mostly insufficient and sometimes scary way.
> 
> The thing is, if the setup is that simple that klibc works, it is very
> likely that the current in-kernel mount code is simple, well tested
> and sufficient enough. If a distro-style intramfs is needed, klibc is
> not usable (see above). The big distros will very unlikely ever pick
> it up. The the remaining use-cases will stay a niche, that, I think,
> does not justify the kernel inclusion of klibc.
> 
> If the whole klibc approach, if not entirely rethought, I doubt it
> will ever go anywhere. In my opinion, with all what I've seen the last
> years, we either work on a full libc in the kernel tree, that can be
> used by normal userspace too, or we leave the tiny stuff to busybox
> and one of the existing tiny libcs.
> 
> Kay

Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

[Will Drewry]

On Sun, Dec 18, 2011 at 2:54 AM, Raz Ben Yehuda <rbenyehuda@manz.com> wrote:
> On Thu, 2011-12-15 at 19:11 +0100, Kay Sievers wrote:
>> On Thu, Dec 15, 2011 at 16:22, H. Peter Anvin <hpa@zytor.com> wrote:
>> > On 12/15/2011 07:19 AM, Raz Ben Yehuda wrote:
>> >>>
>> >>> To which point I have to ask, once again, at which point we stop putting
>> >>> this stuff in the kernel to "bypass the need for initramfs"...
>> >>
>> >> because there are times where we cannot use initramfs. is this a problem
>> >> with way i phrase or with with the whole idea ?
>>
>> I don't see why stuff needs to search a hard-coded list of stuff. That
>> logic seems pretty much backwards to me. You either use the GPT stuff
>> that allows to flag the right partition to boot from a set of
>> partitions, or you go as far as make the kernel parse the filesystem
>> UUID of partitions. But hard-coding search lists on the commandline, I
>> really don't understand.
> Will GPT or fs UUID parsing solve the problem of having the kernel
> think that hda has the root filesystem while hdc has it ?

It's a question of how you address your root filesystem or the
partition containing it. root= is meant for specifying a relatively
unique way to find your root block device (partition) or is overloaded
for use by an initramfs (for FSUUID parsing).  If you can address your
root partition with a UUID, then it doesn't matter what the actual
block device is, the kernel can find it.

The scenario you've laid out is a little confusing.  How does
root_wait interact with a list of block devices?  How do you handle
prioritization if the device come up at different times?  When does it
know to try the next entry? Most of this work seems like it belongs in
either the bootloader or an initramfs.  Then the bootloader can pass
along a unique identifier (like a partition uuid), or if device
enumeration matches, the actual device node name after performing some
boot policy logic.  Using a hard list of device nodes implies a good
bit more boot policy logic than is captured and seems to exceed the
scope of root= by quite a bit.  (Even approaches like md= fit nicely
in the scope that the device specified by root= has an explicit or
kernel-friendly config.)

(And as a side note, those printk(KERN_INFO)s are going to be very
noisy if you have a root_wait scenario.  It's good to go light with
printk()s in this area of the kernel :).

Not sure if this helps, but hopefully it does.
Cheers,
will

>> > There are problems with the whole concept of "cannot use initramfs".  We
>> > allow the initramfs to be integrated with the kernel image for a reason, for
>> > example.
>> >
>> > I'm obviously ranting on this in part to make people think about what they
>> > are doing, and partly to remind that the more complex the in-kernel
>> > root-mounting code get, the more it might be worth reconsidering klibc in
>> > the kernel build tree.
>>
>> I think the whole picture of klibc is confusing and I very much don't
>> want to see that busybox-style hacking in the kernel sources.
>>
>> Distros can not afford to support 2 libcs at bootup, and the distro
>> initramfss gets so complicated today, that a klibc-only solution does
>> not really work. So we end up with 2 libcs in the same initramfs
>> image, which makes zero sense. Leave alone the fact, that the klibc
>> tools duplicate all the stuff that already works in the real root in a
>> completely different and mostly insufficient and sometimes scary way.
>>
>> The thing is, if the setup is that simple that klibc works, it is very
>> likely that the current in-kernel mount code is simple, well tested
>> and sufficient enough. If a distro-style intramfs is needed, klibc is
>> not usable (see above). The big distros will very unlikely ever pick
>> it up. The the remaining use-cases will stay a niche, that, I think,
>> does not justify the kernel inclusion of klibc.
>>
>> If the whole klibc approach, if not entirely rethought, I doubt it
>> will ever go anywhere. In my opinion, with all what I've seen the last
>> years, we either work on a full libc in the kernel tree, that can be
>> used by normal userspace too, or we leave the tiny stuff to busybox
>> and one of the existing tiny libcs.
>>
>> Kay
>
>