[Top][All Lists]

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

internal device representation

From: Hollis Blanchard
Subject: internal device representation
Date: Mon, 17 Jan 2005 23:25:57 -0600

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.

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. 
        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?


reply via email to

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