From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: dab@hp.com, scameron@beardog.cce.hp.com
Subject: Re: Best practice for new linux block driver device naming?
Date: Fri, 8 Mar 2013 16:56:32 -0500 [thread overview]
Message-ID: <20130308215632.GA11989@csclub.uwaterloo.ca> (raw)
In-Reply-To: <20130308200718.GK28545@beardog.cce.hp.com>
On Fri, Mar 08, 2013 at 02:07:18PM -0600, scameron@beardog.cce.hp.com wrote:
> 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?
Well currently, SCSI, SATA, IDE, most well behaved raid controllers,
USB storage, and many others all show up simple as /dev/sd*. You better
have a really good reason to not do so if you make a new controller.
Certainly the IBM serveraid cards I have worked with just present sd*
devices (as well as some sg* devices for the controller and hotswap
backplane and such). I think the CCISS is a sample of a horrible design
as far as the device names in linux are concerned.
By creating a new type of block device you force everyone else to do work
to support it (or choose to ignore your device because no one cares).
By emulating a plain old scsi device interface, everything else just
works, and all the work is done by you in your device driver to pretend
to my just a scsi disk. If you want your device taken seriously,
I don't think you have a choice. Sysadmin's hate things that are
different for no good reason.
--
Len Sorensen
next prev parent reply other threads:[~2013-03-08 21:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-08 20:07 Best practice for new linux block driver device naming? scameron
2013-03-08 21:56 ` Lennart Sorensen [this message]
2013-03-08 22:34 ` scameron
2013-03-08 22:49 ` Lennart Sorensen
2013-03-08 23:05 ` scameron
2013-03-11 18:35 ` Lennart Sorensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130308215632.GA11989@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=dab@hp.com \
--cc=grub-devel@gnu.org \
--cc=scameron@beardog.cce.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).