All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: GRUB device names wrt. ieee1275
Date: Sun, 15 Mar 2009 16:45:31 +0100	[thread overview]
Message-ID: <20090315154531.GD24554@thorin> (raw)
In-Reply-To: <20090314.151417.194555320.davem@davemloft.net>

On Sat, Mar 14, 2009 at 03:14:17PM -0700, David Miller wrote:
> 
> One issue I need to resolve before I can send finalized
> patches out for sparc is about device naming.
> 
> Currently the PowerPC ieee1275 support allows using both device
> aliases and full openfirmware device path names with the usual GRUB
> partition specification concatenated at the end.  For the most part
> this is fine.
> 
> This works for a large group of cases, but in general it will not
> work.
> 
> The problem is two fold:
> 
> 1) "," characters can appear anywhere in an openfirmware path
>    name.  For example my workstations disk is:
> 
> 	/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0
> 
>    There are no quick workarounds for this.  For example, even if we
>    can change the partition fetching code in GRUB to use "strrchr()"
>    instead of "strchr()" in kern/disk.c:grub_disk_open() it will
>    still think the above path has partition ",600000" or something
>    silly like that.
> 
> 2) Disks can have multiple comma seperated components especially
>    on SCSI in OF path names.  For example a disk on target 2,
>    lun 3, would have final path component "disk@2,3"
> 
>    And currently that ",3" would look like a parition specification
>    to GRUB.
> 
> Therefore, I would suggest that we adopt the openfirmware partition
> specification of ":" on GRUB for ieee1275 platforms.

It's not an absolute must that device names are unique.  You can still
identify partitions by their filesystem UUID or label, and in fact this
is what our default scripts (grub-mkconfig) do anyway.

Making GRUB specify partitions differently depending on the platform we're
on seems troublesome, specially if we end up with such long an ugly names.

If we really need this, can't we just assign names dynamically like
hd0, hd1, etc, and keep a memory structure that matches them with the
actual OFW device?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



  parent reply	other threads:[~2009-03-15 15:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-14 22:14 GRUB device names wrt. ieee1275 David Miller
2009-03-14 23:44 ` phcoder
2009-03-15  5:24   ` David Miller
2009-03-15  9:22 ` Vesa Jääskeläinen
2009-03-15 22:52   ` David Miller
2009-03-15 15:45 ` Robert Millan [this message]
2009-03-15 22:41   ` David Miller
2009-03-18 10:18     ` Robert Millan
2009-03-18 20:55       ` David Miller
2009-03-18 21:01         ` David Miller
2009-03-22  0:41           ` phcoder
2009-03-22  0:48             ` phcoder
2009-03-22  1:57               ` David Miller
2009-03-22  1:56             ` David Miller
     [not found]               ` <49C61E3D.3040901@gmail.com>
     [not found]                 ` <20090322.153022.233646325.davem@davemloft.net>
2009-03-22 22:51                   ` phcoder
2009-03-23  1:13                     ` David Miller
2009-03-22 12:22             ` Robert Millan
2009-03-23  4:23               ` David Miller

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=20090315154531.GD24554@thorin \
    --to=rmh@aybabtu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.