[RFC] Some thoughts on device drivers and sysfs

[Adam Belay <abelay@novell.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/