[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB device names wrt. ieee1275

From: Robert Millan
Subject: Re: GRUB device names wrt. ieee1275
Date: Sun, 15 Mar 2009 16:45:31 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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:
> /address@hidden,600000/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden
>    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 "address@hidden,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."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]