device syntax

device syntax

[Hollis Blanchard]

I was thinking about how GRUB specifies device paths using 
"(device,partition)/path" syntax. That's a problem because Open 
Firmware device paths can contain commas. The legal character list is 
the alphanumerics plus ", . _ + -". My Mac's video card is named 
"ATY,Rage128y", and I'm pretty sure I've seen disks with commas in 
their names.

I think what we need is architecture-specific functions that can parse 
a device path into device, partition, and path parts. That would mean 
different syntaxes for the different ports, but I think this is the way 
to go. I see there is already a grub_file_get_device_name() function 
used in a few places; what about also providing 
grub_file_get_partition() and grub_file_get_path() functions?

-Hollis

Re: device syntax

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> I was thinking about how GRUB specifies device paths using
> "(device,partition)/path" syntax. That's a problem because Open
> Firmware device paths can contain commas. The legal character list is
> the alphanumerics plus ", . _ + -". My Mac's video card is named
> "ATY,Rage128y", and I'm pretty sure I've seen disks with commas in
> their names.

Does this problem occur for disks as well in practice?

--
Marco

Re: device syntax

[Tomas Ebenlendr]

> Hollis Blanchard <hollis@penguinppc.org> writes:
> 
> > I was thinking about how GRUB specifies device paths using
> > "(device,partition)/path" syntax. That's a problem because Open
> > Firmware device paths can contain commas. The legal character list is
> > the alphanumerics plus ", . _ + -". My Mac's video card is named
> > "ATY,Rage128y", and I'm pretty sure I've seen disks with commas in
> > their names.
> 
> Does this problem occur for disks as well in practice?
> 
> --
> Marco

Does any 'device' in any port contain '(' or ')'? If so, I propose
escaping or translating to other characters.

The problem with comma can be solved by escaping also, or by searching
for last comma, followed only by digits (provided that we specify
partitions only by numbers).


-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.80162078147

Re: device syntax

[Marco Gerards]

Tomas Ebenlendr <ebik@artax.karlin.mff.cuni.cz> writes:

> Does any 'device' in any port contain '(' or ')'? If so, I propose
> escaping or translating to other characters.

On some architecture, who knows?

> The problem with comma can be solved by escaping also, or by searching
> for last comma, followed only by digits (provided that we specify
> partitions only by numbers).

No, we don't.  AFAIK for BSD slices the following in possible:
(hd0,4,a)

--
Marco

Re: device syntax

[Tomas Ebenlendr]

> Tomas Ebenlendr <ebik@artax.karlin.mff.cuni.cz> writes:
> 
> > Does any 'device' in any port contain '(' or ')'? If so, I propose
> > escaping or translating to other characters.
> 
> On some architecture, who knows?
> 
> > The problem with comma can be solved by escaping also, or by searching
> > for last comma, followed only by digits (provided that we specify
> > partitions only by numbers).
> 
> No, we don't.  AFAIK for BSD slices the following in possible:
> (hd0,4,a)
> 

Then I propose escaping. I think that if we pass device name to
firmware/bios and if we get device name from there, we must deal with
chars '(',')' and ','. So I propose to escape these, such that grub may
ignore them in device name. We gain then consistency, instead of
arch-specific syntax.

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.80193106785

Re: device syntax

[Hollis Blanchard]

On Oct 20, 2004, at 5:13 AM, Tomas Ebenlendr wrote:
>
> Then I propose escaping. I think that if we pass device name to
> firmware/bios and if we get device name from there, we must deal with
> chars '(',')' and ','. So I propose to escape these, such that grub may
> ignore them in device name. We gain then consistency, instead of
> arch-specific syntax.

I'm not sure cross-architectural syntax consistency is an important 
goal.

Open Firmware has its own way of specifying device paths, such as 
"scsi/sd:5,\path\to\file". Users must already be familiar with this 
syntax for other reasons (e.g. to boot GRUB in the first place). 
Directly tranferring that knowledge is important: OF paths are 
confusing enough without escaping characters. If the OF "boot-device" 
variable is "foo", being able to use unmodified "foo" in GRUB is 
critical for new users and convenient for experienced users.

I believe GRUB's consistency with the firmware is more important than 
GRUB's consistency across architectures.

-Hollis

Re: device syntax

[Hollis Blanchard]

On Oct 20, 2004, at 3:58 AM, Marco Gerards wrote:

> Hollis Blanchard <hollis@penguinppc.org> writes:
>
>> I was thinking about how GRUB specifies device paths using
>> "(device,partition)/path" syntax. That's a problem because Open
>> Firmware device paths can contain commas. The legal character list is
>> the alphanumerics plus ", . _ + -". My Mac's video card is named
>> "ATY,Rage128y", and I'm pretty sure I've seen disks with commas in
>> their names.
>
> Does this problem occur for disks as well in practice?

On my briQ, the hda devalias is "/pci@FF500000/isa@6/ide@i1f0/disk@0,0".

-Hollis

Re: device syntax

[M. Gerards]

Quoting Hollis Blanchard <hollis@penguinppc.org>:

> On Oct 20, 2004, at 3:58 AM, Marco Gerards wrote:
> 
> > Hollis Blanchard <hollis@penguinppc.org> writes:
> >
> >> I was thinking about how GRUB specifies device paths using
> >> "(device,partition)/path" syntax. That's a problem because Open
> >> Firmware device paths can contain commas. The legal character list is
> >> the alphanumerics plus ", . _ + -". My Mac's video card is named
> >> "ATY,Rage128y", and I'm pretty sure I've seen disks with commas in
> >> their names.
> >
> > Does this problem occur for disks as well in practice?
> 
> On my briQ, the hda devalias is "/pci@FF500000/isa@6/ide@i1f0/disk@0,0".

But in that case you could use (hda,0), right?

--
Marco

Re: device syntax

[Hollis Blanchard]

On Oct 20, 2004, at 9:44 AM, M. Gerards wrote:

> Quoting Hollis Blanchard <hollis@penguinppc.org>:
>
>> On Oct 20, 2004, at 3:58 AM, Marco Gerards wrote:
>>
>>> Hollis Blanchard <hollis@penguinppc.org> writes:
>>>
>>>> I was thinking about how GRUB specifies device paths using
>>>> "(device,partition)/path" syntax. That's a problem because Open
>>>> Firmware device paths can contain commas. The legal character list 
>>>> is
>>>> the alphanumerics plus ", . _ + -". My Mac's video card is named
>>>> "ATY,Rage128y", and I'm pretty sure I've seen disks with commas in
>>>> their names.
>>>
>>> Does this problem occur for disks as well in practice?
>>
>> On my briQ, the hda devalias is 
>> "/pci@FF500000/isa@6/ide@i1f0/disk@0,0".
>
> But in that case you could use (hda,0), right?

Yes. But are you suggesting we will never see a comma in a device name 
in practice? It should be clear that on systems with more disks, not 
all of them will have devaliases.

The unit address of device nodes is represented in a bus-specific 
encoding, often including a comma as we have seen. Further, it is 
stated convention to encode the name of the device manufacturer into 
the node name with a comma. Have a look at IEEE1275's section on path 
names: the example they give is 
"/sbus@1,f8000000/SUNW,esp@0,800000/sd@1,0".

-Hollis

Re: device syntax

[Yoshinori K. Okuji]

I prefer consistency among various architectures. Note that PC BIOS does 
not offer any name for drives. They are represented by numbers. "hd" 
and "fd" are aliases for numbers.

If we assume that the user knows her firmware very well, we don't need 
to provide "hd" or "fd", since the user should be able to specify 
numbers. Actually, specifying drives by numbers is supported by GRUB 
legacy, but nobody uses it, simply because it is not intuitive.

IMO, we should not assume that the user knows technical details. If we 
write an installer for Open Firmware-based machines, the user may not 
know anything about Open Firmware. The best thing for the user is that 
the user does not have to learn many things. If we provide a consistent 
interface, the user needs to study the single thing. Nothing else.

I think the important goal for GRUB is to provide an easy way for 
ordinary users and a complicated but still useful features for experts. 
So I propose always using simple aliases for drives. If you want to use 
a device name provided by your firmware explicitly, you could use this 
kind of syntax:

devalias foo "/pci@FF500000/isa@6/ide@i1f0/disk@0,0"
multiboot (foo,0)/boot/kernel

EFI uses more horrible device names. This is quoted from EFI How To 
Guide:

Acpi(PNP0A03,1)/PCI(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig1B16CC00-ABD0-0)

If we use escape chacters, it becomes too unreadable.

Okuji

Re: device syntax

[Tomas Ebenlendr]

> I prefer consistency among various architectures. Note that PC BIOS does 
> not offer any name for drives. They are represented by numbers. "hd" 
> and "fd" are aliases for numbers.
> 
> If we assume that the user knows her firmware very well, we don't need 
> to provide "hd" or "fd", since the user should be able to specify 
> numbers. Actually, specifying drives by numbers is supported by GRUB 
> legacy, but nobody uses it, simply because it is not intuitive.
> 
> IMO, we should not assume that the user knows technical details. If we 
> write an installer for Open Firmware-based machines, the user may not 
> know anything about Open Firmware. The best thing for the user is that 
> the user does not have to learn many things. If we provide a consistent 
> interface, the user needs to study the single thing. Nothing else.
> 
> I think the important goal for GRUB is to provide an easy way for 
> ordinary users and a complicated but still useful features for experts. 
> So I propose always using simple aliases for drives. If you want to use 
> a device name provided by your firmware explicitly, you could use this 
> kind of syntax:
> 
> devalias foo "/pci@FF500000/isa@6/ide@i1f0/disk@0,0"
> multiboot (foo,0)/boot/kernel
> 
> EFI uses more horrible device names. This is quoted from EFI How To 
> Guide:
> 
> Acpi(PNP0A03,1)/PCI(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig1B16CC00-ABD0-0)
> 
> If we use escape chacters, it becomes too unreadable.
> 
> Okuji

Hmm, and what if there are quotes, or newlines in name? I think that we
should be able to pass /any/ string to bios/firmware. Question is what
characters we want to escape. If escaped characters will be e.g. quotes,
the need of using this will be very little. If we escape commas, many
names will get horrible. So what about this solution, extended by '\' as
escaping character, using \" for char '"', \\ for '\' and \xxx for
nonprintable or other characters?

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.80479988869

Re: device syntax

[Yoshinori K. Okuji]

On Thursday 21 October 2004 13:26, Tomas Ebenlendr wrote:
> Hmm, and what if there are quotes, or newlines in name? I think that
> we should be able to pass /any/ string to bios/firmware. Question is
> what characters we want to escape. If escaped characters will be e.g.
> quotes, the need of using this will be very little. If we escape
> commas, many names will get horrible. So what about this solution,
> extended by '\' as escaping character, using \" for char '"', \\ for
> '\' and \xxx for nonprintable or other characters?

That should be supported by the command-line interface, surely.

Okuji

Re: device syntax

[Marco Gerards]

Tomas Ebenlendr <ebik@artax.karlin.mff.cuni.cz> writes:

> Hmm, and what if there are quotes, or newlines in name? I think that we
> should be able to pass /any/ string to bios/firmware. Question is what
> characters we want to escape. If escaped characters will be e.g. quotes,
> the need of using this will be very little. If we escape commas, many
> names will get horrible. So what about this solution, extended by '\' as
> escaping character, using \" for char '"', \\ for '\' and \xxx for
> nonprintable or other characters?

Escaping is used to remove the meaning of commandline stuff so you can
pass it to commands.  And the command line parser does this already.
I think we should not use escaping *ever* for other reasons.

--
Marco

Re: device syntax

[Hollis Blanchard]

On Oct 21, 2004, at 5:53 AM, Yoshinori K. Okuji wrote:
>
> IMO, we should not assume that the user knows technical details. If we
> write an installer for Open Firmware-based machines, the user may not
> know anything about Open Firmware.

Fair point.

> I think the important goal for GRUB is to provide an easy way for
> ordinary users and a complicated but still useful features for experts.
> So I propose always using simple aliases for drives. If you want to use
> a device name provided by your firmware explicitly, you could use this
> kind of syntax:
>
> devalias foo "/pci@FF500000/isa@6/ide@i1f0/disk@0,0"
> multiboot (foo,0)/boot/kernel

I suspect it will be a point of confusion that a user can directly use 
"hda" (a real/OF devalias) for their first disk, but if they want to 
use their second disk they must add a devalias command to their 
menu.lst file (or in OF itself).

Also, when booting without a menu.lst, now we need to enter two 
commands. Not difficult, just a little more awkward than it could be.

But on the whole this solution sounds pretty reasonable to me.

-Hollis

Re: device syntax

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

>> devalias foo "/pci@FF500000/isa@6/ide@i1f0/disk@0,0"
>> multiboot (foo,0)/boot/kernel
>
> I suspect it will be a point of confusion that a user can directly use
> "hda" (a real/OF devalias) for their first disk, but if they want to
> use their second disk they must add a devalias command to their
> menu.lst file (or in OF itself).

Why do they have to add it to the menu.lst?  You can add additional OF
devaliases using the OF command line interface.  But there is no
problem to make a temporary one either.

What Okuji described is exactly what I had in mind when I initially
started working on the PPC port.  You can use devaliases in any case,
although it would be nice if it is possible to use a full path, which
is what your patch made possible.  But if the full path conflicts with
the GRUB syntax, it just shouldn't be used...

--
Marco

Re: device syntax

[Hollis Blanchard]

On Oct 28, 2004, at 2:02 PM, Marco Gerards wrote:

> Hollis Blanchard <hollis@penguinppc.org> writes:
>
>>> devalias foo "/pci@FF500000/isa@6/ide@i1f0/disk@0,0"
>>> multiboot (foo,0)/boot/kernel
>>
>> I suspect it will be a point of confusion that a user can directly use
>> "hda" (a real/OF devalias) for their first disk, but if they want to
>> use their second disk they must add a devalias command to their
>> menu.lst file (or in OF itself).
>
> Why do they have to add it to the menu.lst?  You can add additional OF
> devaliases using the OF command line interface.  But there is no
> problem to make a temporary one either.

There should be no need.

> What Okuji described is exactly what I had in mind when I initially
> started working on the PPC port.  You can use devaliases in any case,
> although it would be nice if it is possible to use a full path, which
> is what your patch made possible.  But if the full path conflicts with
> the GRUB syntax, it just shouldn't be used...

I'm afraid I don't agree. GRUB should not be limited to the least 
common denominator of all the architectures it may be ported to. The 
GRUB device syntax was written solely with x86 PCs in mind; surely we 
can agree that all similar limitations have already been outgrown even 
on PCs themselves?

In fact, to extend the original PC BIOS -> "hd0" numbering scheme, we 
*could* enumerate every block device found in the Open Firmware device 
tree, and name them all "hd0" through "hd47". The user confusion that 
already exists on PCs would be multiplied greatly. That is not a good 
idea.

devaliases are fine and are convenient, but full device paths are 
important and should be equally usable (and not by going through extra 
steps to pretend that "/pci@FF500000/isa@6/ide@i1f0/disk@0,0" is really 
"hd0" just because there's a comma in there).

People who focus on PCs and Macintosh understandably might not consider 
this important, but on servers this is a very real issue.

-Hollis