Skip to contentSkip to conversation

Flaw in the driver-model implementation of attributes

DISCUSSION Clayton Weaver 3 participants 3 messages Jun 18, 2003 – Jun 19, 2003

lore
Share & tools
lore
#0 lore raw

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

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

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

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?

Vfs models are virtual, so vfs having its own sysfs tree for block devices does not create any confusion relative to an organization based on the the hardware connection tree in the machine.

But when you are considering where to place attributes meant to be evaluated by low-level hardware drivers, it is easier to follow if the organization follows a

bus (ie pci, for example)

    host-controller/mux
      bus
        device
          [bus
            device...]

organization. (The bracketed branch is for a cascade or bridge device.)

So how does "class" fit into that model? Does it signify a domain of buses, a set of bus attributes (should be under the "/sysfs/bustype/busnum/" in that case), a set of controller attributes, a set of device attributes, or some software abstraction like block or char device attributes?

Regards,

Clayton Weaver
<mailto: [email protected]>

Signature · 6 lines
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers
#1 lore raw
Quoted 2 lines · Clayton Weaver

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

Sounds like we're getting there!

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

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.

#2 lore raw
Quoted 5 lines
Quoted 2 lines

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.

Not quite. A class represents a class of devices, or the function that a device performs, e.g. disk or sound.

Quoted 7 lines
Quoted 3 lines

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.

No. If you want to go that far, 'devices' could go under there as well, and we'd eventually just have one top-level directory: /sys/class :)

The top-level directories in sysfs represent classes of objects, not necessarily tied to any driver model concepts. The reason it's so driver-model heavy now is because that's how the whole thing originated.

-pat