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