grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
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


  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).