All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <abelay-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
To: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>,
	Patrick Mochel
	<mochel-og82NyAXoxR0I81aPRRTmR2eb7JE58TQ@public.gmane.org>
Cc: linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC] Some thoughts on device drivers and sysfs
Date: Sun, 27 Mar 2005 14:24:59 -0500	[thread overview]
Message-ID: <1111951499.3503.87.camel@localhost.localdomain> (raw)

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

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



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



WARNING: multiple messages have this Message-ID (diff)
From: Adam Belay <abelay@novell.com>
To: Greg KH <greg@kroah.com>, Patrick Mochel <mochel@digitalimplant.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@lists.osdl.org
Subject: [RFC] Some thoughts on device drivers and sysfs
Date: Sun, 27 Mar 2005 14:24:59 -0500	[thread overview]
Message-ID: <1111951499.3503.87.camel@localhost.localdomain> (raw)

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



             reply	other threads:[~2005-03-27 19:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-27 19:24 Adam Belay [this message]
2005-03-27 19:24 ` [RFC] Some thoughts on device drivers and sysfs Adam Belay
     [not found] ` <1111951499.3503.87.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2005-03-27 20:53   ` Arioch
2005-03-27 20:53     ` Arioch
2005-03-27 21:08   ` Dominik Brodowski
2005-03-27 21:08     ` Dominik Brodowski
     [not found]     ` <20050327210853.GA18358-JwFqNg2GrOVrgjWwlLH9qw@public.gmane.org>
2005-03-27 21:27       ` Adam Belay
2005-03-27 21:27         ` Adam Belay
     [not found]         ` <1111958844.3503.100.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2005-03-27 21:43           ` Dominik Brodowski
2005-03-27 21:43             ` Dominik Brodowski
     [not found]             ` <20050327214309.GA18745-JwFqNg2GrOVrgjWwlLH9qw@public.gmane.org>
2005-03-27 22:18               ` Adam Belay
2005-03-27 22:18                 ` Adam Belay
2005-03-27 21:25   ` Jon Smirl
2005-03-27 21:25     ` Jon Smirl
2005-03-29  5:03   ` Greg KH
2005-03-29  5:03     ` Greg KH
     [not found]     ` <20050329050345.GB7937-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2005-03-29  6:33       ` Dmitry Torokhov
2005-03-29  6:33         ` [linux-pm] " Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111951499.3503.87.camel@localhost.localdomain \
    --to=abelay-et1tbqhtxzrqt0dzr+alfa@public.gmane.org \
    --cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=mochel-og82NyAXoxR0I81aPRRTmR2eb7JE58TQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.