Chapter 20. 14h30 - The sysfs Filesystem

The sysfs Filesystem

Patrick Mochel

Patrick is a very good speaker; I enjoy going to his talks. Although this talk probably wasn't too interesting to people who use sysfs on a quasi-daily basis, it was a very interesting overview talk perfectly aimed at people like me (i.e. people who have started using 2.6.x but haven't really written any kernel code in it yet).

What

• based on ramfs, said to be one of the simplest drivers in the kernel (roughly 300 lines of code)

• provides an easy kernel/userspace interface

• exports kobjects

• enforces a very strict hierarchy so that developers can't stick files all over the virtual tree; the location is relative to (a subdirectory of) the device's parent

• the information stored is mostly ASCII, almost always one value per file (sort of like a key:value pair, the key being the filename, the value being its contents)

• the files/directories/symlinks are dynamically created and module/thread safe; if you pull out a hotplug device, read()s will fail gracefully

History

• it was called ddfs...

• which became driverfs

• then other systems wanted to use it

• so it was wrapped up along with kobjects, now the entire kernel uses it

Kobjects

• kobjects resulted from a desire to place all common data fields into one structure

• added to it were "behind the scenes" operations so things that needed to be done for every driver could be done without the developer's intervention (reduces the chances of making a mistake)

properties

• directories -> kobjects

• files -> kobject attributes

• symlinks -> relationship between kobjects

why

• it started off because it was part of the udev design (required by udev)

• then it started getting more use by other subsystems

• more and more subsystems are starting to switch over to it

why is it so great

• it is very easy for both the kernel and userspace to access and use

• it opens doors and forms the basis of many other projects:

  • debugfs

  • configfs

  • libfs

  • ... (and others)

how is it bad

• sysfs is far from perfect

• some of its shortcomings include:

  1. kobjects and sysfs

     • kobjects are messy

     • they are difficult to use in a simple manner

     • requires lots of extra things to be part of the kernel

     • each directory needs its own separate kobject, even if its just for organizational purposes

  2. external access

     • there is no standard library, no standard way of accessing data in sysfs trees

     • there is no "transaction" locking (i.e. if you need the value from two files there's no way to ensure that you get a snapshot of both at the exact same instant in time, while you're reading one value, the value in the other file could be changing)

     • there are no userspace visualization tools

  3. system support

     • sysfs requires a fair amount of memory, which might be harder to come by in some systems such as those in embedded environments

     • there's no reliable way to support sysfs over networks for clustering

     • the sysfs system doesn't have code in it to handle being virtualized (such as with Xen or other such similar environments)