[lkml]   [2002]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: the userspace side of driverfs

On 10 Sep 2002, Nicholas Miell wrote:

> I see documentation describing the kernel interface for driverfs, but
> not much is available describing the userspace interface to driverfs --
> i.e. the format of all those files that driverfs exports.
> In order to prevent driverfs from becoming the maze of twisted files,
> all different that is /proc, these details need to be specified now,
> before it's too late.

I agree. There has been a lot of talk on this topic, but I don't think
much has gotten down on paper, though there might be some in the

The main ideal that we're shooting for is to have one ASCII value per
file. The ASCII part is mandatory, but there will definitely be exceptions
where we will have an array of or multiple values per file. We want to
minimize those instances, though. Both for the sake of easy parsing, but
also for easy formatting within the drivers.

> Some issues I can think of off the top of my head:
> - Can I safely assume that, for all normal files named X in driverfs,
> that they have the exact same format and purpose?

Yes. One of the pipe dreams I have, which will hopefully become a reality
in the future is to document the attributes when they're defined with a
docbook-like comment. These can then be extracted and inserted into a

We're working on a utility that abstracts the layout of driverfs from the
user. This will allow you do things like list all the devices and drivers
of a particular bus or class type, as well as display their attributes.
With a database of attribute descriptions, you can provide desciptive
context along with the value of the attribute.

> - The "resource" files export resource structs, however the flags member
> of the struct uses bits that aren't exported by the kernel and are
> likely to change in the future. Also, some of the flags bits are
> reserved for use by the bus that the resource lives on, but the bus type
> isn't specified by the resource file, which requires the app to parse
> the path name in order to figure out which bus the resource refers to.

The flags bit is a good point, and should probably be removed.

Taking a step back, I would like to note that it would be nice to do
something at a higher level with the resource structures; i.e. put them in
struct device and deal with them in the driver model core. This is ways
out, though if it happens, it will likely have repercussions in their
driverfs representation..

> - "name" isn't particularly consistent. Sometimes it requires parsing to
> be useful ("PCI device 1234:1234", "USB device 1234:1234", etc.",
> sometimes it's the actual device name, sometimes it's something strange
> like "Hub/Port Status Changes".

'name' is better referred to as 'description'. It's a bus-specified string
that describes the device. The bus is allowed to do as it pleases with it.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.088 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site