Re: Flaw in the driver-model implementation of attributes

["Kevin P. Fleming" <kpfleming@cox.net>]

Clayton Weaver wrote:

> (Doubting that there is a sysfs faq anywhere
> yet, ...)

Sounds like we're getting there!

> 
> What is a sysfs "class", as in /sys/class/...?

It is an abstraction. It is a group of objects that implement common 
functionality, and have common attributes and behaviors.

> 
> What do sysfs classes have in common? How is
> a /sys/class/ different from a /sys/devices,
> /sys/bus, etc?

/sys/bus, /sys/block are just special-case classes that get their own 
top-level directory. They could just easily have been put under 
/sys/class/block, /sys/class/bus.

> 
> In re: the current discussion, are the "usb-storage" attributes under discussion
> something that the vfs would need to know
> about(/sys/block/)? Something that a pci
> bus would need to know about? Something that
> a usb controller would need to know about?

IMHO, no. Any attributes specific to a usb-storage device are not 
something that any other layer would care about. As an example, a 
flash-memory USB key I have here support software write protection; 
while I don't know if the usb-storage driver currently exposes that, it 
could, and that would be very specific to usb-storage. Any userspace 
application that wanted to manipulate the state of that protection would 
look at /sys/class/usb-storage/... for devices it could potentially 
manage. It doesn't need to how or where those devices are connected, or 
even what type of media they may be. It only needs to know that they are 
usb-storage devices, and that they have a "writeprotect" attribute 
exposed in the appropriate place.