Hi,
I'm just wondering if there are best pratices for new linux block
drivers that are adding new devices nodes of which grub is currently
not cognizant.
E.g. when we added the HP Smart Array cciss driver to the kernel
many years ago, it had device nodes like /dev/cciss/c*d*, and there's
code in grub to handle this in util/getroot.c, in
convert_system_partition_to_system_disk():
/* If this is a CCISS disk. */
if (strncmp ("cciss/c", p, sizeof ("cciss/c") - 1) == 0)
{
/* /dev/cciss/c[0-9]+d[0-9]+(p[0-9]+)? */
p = strchr (p, 'p');
if (p)
{
*is_part = 1;
*p = '\0';
}
return path;
}
And there is similar code for other weird device names is in there
as well.
Ideally, I'm hoping there's a way to introduce new devices nodes
with a new block driver which does not any require grub modifications.
Looking over the code, it's not clear to me whether or not this is
possible, and if it is, how to do it, what the constraints may be, etc.
Currently I have a new driver which adds devices like /dev/sop0 with
partitions like /dev/sop0p1, /dev/sop0p2, etc.
If there is some better way to do this to enable grub to work with
these devices, it is not yet too late for me to change it.
Or on the other hand, if it turns out that it is not possible to add
new block devices to linux and have grub support for those devices without
also modifying grub, then I wonder if it might be worth looking into to
adding some kind of shared device namespace for block devices to linux, so
new block drivers could use that and have a common naming system for block
devices,
and grub could be modified to support this new common naming system,
much as scsi hba device drivers share the /dev/sd* namespace for their attached
disks, so it is easy to add new scsi hba drivers to linux and automatically have
grub support for them. It would be nice if it were similarly easy to add new
block device drivers to linux without also requiring modifications to grub.
(It also occurs to me that this is such an obvious desire that if it is not
already supported, perhaps there's a good reason why not, but if that's the
case, I'm don't know what the reason might be.)
Thoughts?
Thanks,
-- steve
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
