internal device representation

internal device representation

[Hollis Blanchard]

Nobody has replied to my previous mail about device syntax, so I will 
assume that means you all agree that I'm right about requiring 
different device syntaxes for different architectures. ;)

We also need to think about how to represent a device internally. Here 
are two complete Open Firmware file paths (using device aliases for 
simplicity). Everything preceding the colon is the device specifier; 
everything following the colon is an argument to the device's "open" 
method.
	disk:partition,filename
	net:siaddr,filename,ciaddr,giaddr,bootp-retries,tftp-retries

In the disk case, "filename" is the last part of the string, which is 
convenient in that it allows us to simply append a file path (e.g. 
"grub.conf") to a device specifier (e.g. "disk:partition,").

However, there is no guarantee that "filename" is the last device 
argument. As you can see in the TFTP (network) example, "filename" 
comes mid-string. If we boot grub via TFTP like that, we naturally must 
preserve all those arguments when retrieving grub.conf.

That suggests that when code calls e.g. grub_file_get_device_name(), 
the result is more complicated than a string. Instead it could be an 
architecture-specific structure, like this:
struct device {
	char *device_path; // e.g. "/pci@FF500000/isa@6/ide@i1f0/disk@0,0"
	char *args[]; // e.g. "partition", NULL
}

grub_file_get_device() would allocate and initialize this structure, 
passing it as an opaque type back to generic code. 
Architecture-specific code would know how many arguments to expect in 
the "args" array from the type of node specified by "device_path" (i.e. 
a getprop call for OF).

x86 could use the same string representation it does now:
struct device {
	char *name;
}
or it might even clean up some code to add
	int partition;
	char *filename;
but that's not necessary.

Please take a look at the generic code between grub_device_open() and 
driver ->open(). What sort of accessor functions would each 
architecture need to provide to manipulate a struct device, if any?

-Hollis

Re: internal device representation

[Yoshinori K. Okuji]

On Tuesday 18 January 2005 06:25, Hollis Blanchard wrote:
> Nobody has replied to my previous mail about device syntax, so I will
> assume that means you all agree that I'm right about requiring
> different device syntaxes for different architectures. ;)

I don't agree. Sorry, I forgot to send a reply again.

You assume that aliases are made by a firmware, but I actually meant 
that GRUB could make arbitrary aliases in itself, since GRUB has its 
own device drivers. For example:

alias hd0 /path/to/a/device

This does not have to call Open Firmware, because GRUB itself can map 
"hd0" to "/path/to/a/device" transparently.

I agree that you can use different naming conventions from architecture 
to architecture, but I believe that the basic syntax should be the 
same. For instance, I accept that you use "sd0" for a SCSI disk, which 
is difficult on PC BIOS.

Okuji

Re: internal device representation

[Hollis Blanchard]

On Jan 18, 2005, at 5:04 AM, Yoshinori K. Okuji wrote:

> On Tuesday 18 January 2005 06:25, Hollis Blanchard wrote:
>> Nobody has replied to my previous mail about device syntax, so I will
>> assume that means you all agree that I'm right about requiring
>> different device syntaxes for different architectures. ;)
>
> You assume that aliases are made by a firmware, but I actually meant
> that GRUB could make arbitrary aliases in itself, since GRUB has its
> own device drivers. For example:
> ...

You have not addressed the question raised in this mail, so I will try 
to rephrase it... this mail is not about user-visible syntax; this is 
about how we represent a device internally.

In the netboot case, we can boot like this:
	boot net:192.168.0.1,grubof,192.168.0.2
Inside grub, /chosen/bootpath looks like this:
	/pci@1f,0/pci@1,1/network@1,1

[So let's pretend we don't have any problem with commas or syntax (as 
that is the subject of the other mail), and we set the "prefix" 
variable to be "net" or "(nd0)" or whatever you like.]

Now we want to retrieve grub.conf. However, we can't just stick 
"grub.conf" on the end of that string and expect it to work: 
"(nd0)/grub.conf" would become "net:,grub.conf" to the OF driver, and 
now we have lost the server and client IP addresses.

This suggests that we need to preserve a separated device specifier, 
rather than flattening it into a string. The specifier must keep the 
device path and device arguments separated, for later recombination 
with the new filename.

struct device {
	char *device_path = "net"
	char *args = ["192.168.0.1", NULL, "192.168.0.2"]
}
... and the grub Open Firmware driver knows to insert "filename" into 
args[1].

-Hollis

Re: internal device representation

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> In the netboot case, we can boot like this:
> 	boot net:192.168.0.1,grubof,192.168.0.2

What does this mean?  The first IP address is the server, the second
is our own?

> Inside grub, /chosen/bootpath looks like this:
> 	/pci@1f,0/pci@1,1/network@1,1
>
> [So let's pretend we don't have any problem with commas or syntax (as
> that is the subject of the other mail), and we set the "prefix"
> variable to be "net" or "(nd0)" or whatever you like.]
>
> Now we want to retrieve grub.conf. However, we can't just stick
> "grub.conf" on the end of that string and expect it to work:
> "(nd0)/grub.conf" would become "net:,grub.conf" to the OF driver, and
> now we have lost the server and client IP addresses.

For GRUB Legacy there is the ifconfig command to configure the device.

> This suggests that we need to preserve a separated device specifier,
> rather than flattening it into a string. The specifier must keep the
> device path and device arguments separated, for later recombination
> with the new filename.
>
> struct device {
> 	char *device_path = "net"
> 	char *args = ["192.168.0.1", NULL, "192.168.0.2"]
> }

How about the data member of grub_dev?

> ... and the grub Open Firmware driver knows to insert "filename" into
> args[1].

It would be nice if it can be kept hidden from the user that OF is
used and make it work like GRUB Legacy did or so.

Thanks,
Marco