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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
