A critical look at sysfs attribute values [LWN.net]

A critical look at sysfs attribute values

Posted Mar 19, 2010 20:41 UTC (Fri) by cmccabe (guest, #60281)
Parent article: A critical look at sysfs attribute values

It really seems like getting bad blocks information would best be done with Netlink, rather than sysfs.

With sysfs, if you follow the "one value per file" philsophy, you could create a potentially unlimited number of files, in view of how many blocks hard drives have these days. If you don't follow the philsophy, you end up with something that's probably both ugly and buggy.

With netlink, you don't pay the cost unless someone actually asks for the data. With sysfs, you have to create the inodes, whether or not anyone actually uses them. And of course, there are the atomicity issues. With netlink, it's a lot easier for the application to ask only for the data it wants. Userspace can do something reasonable like reading only part of the data at a time.

It also makes operations on these bad blocks a lot more natural. You can do something like query which blocks are bad, and then run operations on these blocks, as part of your send/receive netlink session.

You'd have to ask upstream if they'd be willing to accept a netlink solution first, of course. But I think this is a situation where sysfs is just a square peg in a round hole.

(Log in to post comments)

Netlink??

Posted Mar 22, 2010 22:27 UTC (Mon) by neilbrown (subscriber, #359) [Link]

I fail to understand the general fascination with netlink.

My guess is that it is a bit like debugfs "the only rule is that there are no rules". With netlink you can do whatever you like - it is like ioctl but without the guilt.

I would always use files in a filesystem for any interaction between kernel and user-space. You can easily do large files (using seqfile). You can easily to query-response transactions using simple_transaction_* (see the nfsd filesystem).

But I don't think we should make these choices 'because it is easy' or 'because we can' but rather 'because it is right'. Determining what is 'right' is a challenge. In a lot of cases I think 'one item per file' is 'right. But I don't think it is always right. Hence the desire to explore how sysfs is actually used in order to find a new interpretation of "right" that both acknowledges everything that currently works well, but also includes those cases that currently aren't supported well.

Just using netlink (or debugfs) because it doesn't impose rules sounds too much like taking the broad road with the wide gate - I hope you know where that leads.

Netlink??

Posted Mar 25, 2010 7:02 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

For a lot of reasons netlink is a very good fit for the working with the networking stack. But note the networking stack has /proc/sys/net also.

Netlink isn't too bad for general event based things.

Beyond that I would not encourage use of netlink.

I'm not certain what to do with bad blocks. They seem like part of an abstraction leaking through so I'm not certain we want an interface that we have to maintain for all time describing them for dealing with them.