driverfs API Updates

From: Patrick Mochel (mochel@osdl.org)
Date: Mon Aug 05 2002 - 14:17:13 EST


A series of driverfs changes went into Linus' tree last Friday. This is a
short summary of those changes, and some notes on how to use them.

Firstly, I changed the name of the structure that must be declared
from struct driver_file_entry to struct device_attribute. This more
accurately represents what is going on.

I've also created a macro[1] for defining device attributes, that goes
like this:

DEVICE_ATTR(name,"strname",mode,show,store);

This will create a structure by the name of 'dev_attr_##name', where
##name is the first parameter, which can then be passed to
device_create_file(). [2]

The definition of device_remove_file has changed to:

void device_remove_file(struct device * dev, struct device_attribute *
attr);

(The second parameter is now the same type as what is passed to
device_create_file, for consistency's sake (instead of a char *)).

I've added support for bus and device driver attributes. The mechanism
for manipulating them is analogous to that of device attributes. To
declare them, you do:

BUS_ATTR(name,"strname",mode,show,store);
DRIVER_ATTR(name,"strname",mode,show,store);

which create the objects

struct bus_attribute bus_attr_##name;

and

struct driver_attribute driver_attr_##name;

respectively.

You can then use

int bus_create_file(struct bus_type *, struct bus_attribute *);
void bus_remove_file(struct bus_type *, struct bus_attribute *);

int driver_create_file(struct device_driver *, struct driver_attribute *);
void driver_remove_file(struct device_driver *, struct driver_attribute
*);

To add and remove them.

Bus attribute files appear in the bus's directory (bus/<bus>/ under
the driverfs mountpoint).

Driver attributes appear in the driver's directory
(bus/<bus>/<driver>/ under the driverfs mountpoint).

The bus show and store routines are identical to the device show and
store routines, though they take a pointer of type struct bus_type as
the first parameter.

Similarly for drivers; they take a struct device_driver * as the first
parameter.

Please see include/linux/device.h for the structure definitions, and
drivers/base/fs/*.c for implementation details.

driverfs now has the ability to support attributes for any object
type. I've updated the documentation
(Documentation/filesystems/driverfs.txt) to hopefully include enough
information to hack on it. I'm also open to all questions and
suggestions, so please feel free to ask.

Thanks,

        -pat

[1]: The reason for the macro is because the driverfs internals
have changed enough to be able to support attributes of any type. In
order to do this in a type-safe manner, we have a generic object type
(struct attribute) that we use. We pass this to an intermediate layer
that does a container_of() on that object to obtain the specific
attribute type.

This means the specific attribute types have an embedded struct
attribute in them, making the initializers kinda ugly. I played with
anonymous structs and unions to have something that could
theoretically work, but they apparently don't like named
initializers.

[2]: I wanted to consolidate the first two parameters, but I couldn't
find a way to stringify ##name (or un-stringify "strname"). Is that
even possible?

-
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/



This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:28 EST