grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: scameron@beardog.cce.hp.com
To: grub-devel@gnu.org
Cc: dab@hp.com, scameron@beardog.cce.hp.com
Subject: Best practice for new linux block driver device naming?
Date: Fri, 8 Mar 2013 14:07:18 -0600	[thread overview]
Message-ID: <20130308200718.GK28545@beardog.cce.hp.com> (raw)


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



             reply	other threads:[~2013-03-08 21:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 20:07 scameron [this message]
2013-03-08 21:56 ` Best practice for new linux block driver device naming? Lennart Sorensen
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=20130308200718.GK28545@beardog.cce.hp.com \
    --to=scameron@beardog.cce.hp.com \
    --cc=dab@hp.com \
    --cc=grub-devel@gnu.org \
    /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).