Adam Belay
2005-03-27 19:33:06 UTC
One of the original design goals of sysfs was to provide a standardized
location to keep driver configuration attributes. Although sysfs
handles this very well for bus devices and class devices, there isn't
currently a method to export attributes for device drivers and their
specific bound device instances to userspace.
I would like to propose that we create a new type of device that would
act as the layer between physical (bus devices) and logical (class
devices). It could be referred to as a "driver device". Driver devices
would bind to a bus devices and create one or more class devices. Their
type would be of "struct device_driver". As an example, this would
allow us to move something like /proc/driver/emu10k1/0000:01:09.0 into
sysfs.
(physical) | (logical)
------------------------------------------------
|bus device --> driver device --> class device |
------------------------------------------------
struct driver_device {
struct list_head node;
unsigned long id;
struct kobject kobj;
struct device_driver *drv;
struct device *dev;
int state;
};
In sysfs, a new directory could be created to represent driver devices.
It might look like the following:
bus
|
\- pci
|
\- devices
|
\- link to device0
\- link to device1
\- drivers
|
\- link to random_drv (in other words random_drv can drive this bus)
device
|
\- device0
[...]
\- device1
[...]
driver (this directory is new)
|
\- random_drv
|
\- 0 (a sequential instance number) <-- this is a driver device
|
\- link to device0
\- link to class0
\- a file to control driver state (start, stop, etc.)
\- driver attributes for this link
\- 1
|
\- link to device1
\- link to class1
\- a file to control driver state
\- driver attributes for this link
class
|
\-some_type
|
\- class0
[...]
\- class1
[...]
This would allow us to represent per-device driver attributes in sysfs.
As an added benefit, driver devices would allow the tracking and control
of driver state, which may be needed for dynamic power management. I
look forward to any comments.
Thanks,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
location to keep driver configuration attributes. Although sysfs
handles this very well for bus devices and class devices, there isn't
currently a method to export attributes for device drivers and their
specific bound device instances to userspace.
I would like to propose that we create a new type of device that would
act as the layer between physical (bus devices) and logical (class
devices). It could be referred to as a "driver device". Driver devices
would bind to a bus devices and create one or more class devices. Their
type would be of "struct device_driver". As an example, this would
allow us to move something like /proc/driver/emu10k1/0000:01:09.0 into
sysfs.
(physical) | (logical)
------------------------------------------------
|bus device --> driver device --> class device |
------------------------------------------------
struct driver_device {
struct list_head node;
unsigned long id;
struct kobject kobj;
struct device_driver *drv;
struct device *dev;
int state;
};
In sysfs, a new directory could be created to represent driver devices.
It might look like the following:
bus
|
\- pci
|
\- devices
|
\- link to device0
\- link to device1
\- drivers
|
\- link to random_drv (in other words random_drv can drive this bus)
device
|
\- device0
[...]
\- device1
[...]
driver (this directory is new)
|
\- random_drv
|
\- 0 (a sequential instance number) <-- this is a driver device
|
\- link to device0
\- link to class0
\- a file to control driver state (start, stop, etc.)
\- driver attributes for this link
\- 1
|
\- link to device1
\- link to class1
\- a file to control driver state
\- driver attributes for this link
class
|
\-some_type
|
\- class0
[...]
\- class1
[...]
This would allow us to represent per-device driver attributes in sysfs.
As an added benefit, driver devices would allow the tracking and control
of driver state, which may be needed for dynamic power management. I
look forward to any comments.
Thanks,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------