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
On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote:
> 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.
Drivers can add (e.g. in ->probe) attributes for devices using
extern int device_create_file(struct device *device, struct device_attribute
* entry);
and delete them (e.g. in ->remove) using
extern void device_remove_file(struct device * dev, struct device_attribute
* attr);
and there's also
extern int driver_create_file(struct device_driver *, struct
driver_attribute *);
extern void driver_remove_file(struct device_driver *, struct
driver_attribute *);
Dominik
On Sun, 27 Mar 2005 14:24:59 -0500, Adam Belay <[email protected]> wrote:
> 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.
Isn't there already a way to do this? I recall some discussion lkml
about six months ago about doing it. I tried googling for it but
couldn't find it. It may not have been implemented.
--
Jon Smirl
[email protected]
On Sun, 2005-03-27 at 23:08 +0200, Dominik Brodowski wrote:
> On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote:
> > 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.
You're right, I should have worded this differently.
>
> Drivers can add (e.g. in ->probe) attributes for devices using
> extern int device_create_file(struct device *device, struct device_attribute
> * entry);
> and delete them (e.g. in ->remove) using
> extern void device_remove_file(struct device * dev, struct device_attribute
> * attr);
>
> and there's also
>
> extern int driver_create_file(struct device_driver *, struct
> driver_attribute *);
> extern void driver_remove_file(struct device_driver *, struct
> driver_attribute *);
>
>
> Dominik
Yes, I'm aware of these functions but they pollute the bus level
namespace. I'm interested in reactions to this alternative approach. I
wanted to explore the possibility of making a device driver instance a
separate component with its own individual state and relationships.
Adam
On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
> > extern int device_create_file(struct device *device, struct device_attribute
> > * entry);
> > and delete them (e.g. in ->remove) using
> > extern void device_remove_file(struct device * dev, struct device_attribute
> > * attr);
> >
> > and there's also
> >
> > extern int driver_create_file(struct device_driver *, struct
> > driver_attribute *);
> > extern void driver_remove_file(struct device_driver *, struct
> > driver_attribute *);
> >
> >
> > Dominik
>
> Yes, I'm aware of these functions but they pollute the bus level
> namespace. I'm interested in reactions to this alternative approach. I
> wanted to explore the possibility of making a device driver instance a
> separate component with its own individual state and relationships.
To be honest, I don't consider this to be a pollution of the "bus"
namespace, but I fear that having two different places for somewhat similar,
or even equal, data adds unneeded complexity to the driver model. In what
specific instances has the current design limited or obstructed your
intentions?
Dominik
On Sun, 2005-03-27 at 23:43 +0200, Dominik Brodowski wrote:
> On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
> > > extern int device_create_file(struct device *device, struct device_attribute
> > > * entry);
> > > and delete them (e.g. in ->remove) using
> > > extern void device_remove_file(struct device * dev, struct device_attribute
> > > * attr);
> > >
> > > and there's also
> > >
> > > extern int driver_create_file(struct device_driver *, struct
> > > driver_attribute *);
> > > extern void driver_remove_file(struct device_driver *, struct
> > > driver_attribute *);
> > >
> > >
> > > Dominik
> >
> > Yes, I'm aware of these functions but they pollute the bus level
> > namespace. I'm interested in reactions to this alternative approach. I
> > wanted to explore the possibility of making a device driver instance a
> > separate component with its own individual state and relationships.
>
> To be honest, I don't consider this to be a pollution of the "bus"
> namespace, but I fear that having two different places for somewhat similar,
> or even equal, data adds unneeded complexity to the driver model. In what
> specific instances has the current design limited or obstructed your
> intentions?
>
Fair enough. I just wanted to float this possibility. I appreciate
your comments. The original intention for this design was to begin
working on a framework for driver layering. (ex. snd-intel8x0m -> ac97,
or the pci express bus abstraction) I was considering the possibility
of having driver devices with parent and child relationships that
reflect the internal layering of Linux drivers. I haven't really had a
chance to fully develop this idea, so at this point, driver layering and
my original email are just abstract concepts.
Adam
Adam Belay ?????:
> 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).
why not using D-BUS to allow lowlevel drivers to expose its features to
userspace?
On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote:
> 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.
Hm, what's device_create_file(), device_remove_file(), and DEVICE_ATTR()
for? A number of drivers use these functions today to add their own
driver specific attributes to a device they control.
Then, userspace can just do a simple:
ls /sys/bus/pci/drivers/my_foo_driver/
to see all devices on the PCI bus that are controlled by that driver.
Then it can go into those directories and cat out the specific
information if needed.
Is there something that is lacking in the current code that you would
like to see present? I don't think that adding another layer on top of
a device would help out much here.
thanks,
greg k-h
On Tuesday 29 March 2005 00:03, Greg KH wrote:
> On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote:
> > 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.
>
> Hm, what's device_create_file(), device_remove_file(), and DEVICE_ATTR()
> for? A number of drivers use these functions today to add their own
> driver specific attributes to a device they control.
>
> Then, userspace can just do a simple:
> ls /sys/bus/pci/drivers/my_foo_driver/
> to see all devices on the PCI bus that are controlled by that driver.
> Then it can go into those directories and cat out the specific
> information if needed.
It probably would be nice if all driver-specific device attributes would be
grouped under /sys/devices/.../<blah_device>/drvattr/* so their names would
not clash with names of driver core attributes.
Unfortunately that would mean we are breaking userspace again...
--
Dmitry