On Thu, Aug 20, 2009 at 09:09:21AM +0300, Avi Kivity wrote:
On 08/20/2009 01:16 AM, Joel Becker wrote:With an ioctl structure, I can't take a look at what the values
With an ioctl() that isn't (well) documented, you have to goAn ioctl structure and a configfs/sysfs readdir provide similar
read the structure and probably even read the code that uses the
structure to be sure what you are doing.
information (the structure also provides the types of fields and
isn't able to hide some of these fields).
look like unless I read the code or write up a C program. With a
configfs file, I can just cat the thing.
"Looking at the values" is what I meant by discouragingMost ioctls don't tell you that either. It certainly won't let
documentation. That implies looking at a self-documenting live
system. But that tells you nothing about which fields were added in
which versions, or fields which are hidden because your hardware
doesn't support them or because you didn't echo 1> somewhere.
you know that field foo_arg1 is ignored unless foo_arg2 is set to 2, or
things like that.
The problem of versioning requires discipline either way. It's
not obvious from many ioctls. Conversely, you can create versioned
configfs items via attributes or directories (same for sysfs, etc).
The maintainer of the subsystem should provide a library that talksAgain, that helps the user nothing. I don't know it exists. I
to the binary interface and a CLI program that talks to the library.
Boring nonkernely work. Alternatively a fuse filesystem to talk to
the library, or an IDL can replace the library.
don't have it installed. Unless it ships with the kernel, I have no
idea about it.
Many things start oriented at people and then, if they're useful,It's work to convert either way. Outside of fast-path things,
cross the lines to machines. You can convert a machine interface to
a human interface at the cost of some work, but it's difficult to
undo the deficiencies of a human oriented interface so it can be
used by a program.
the time it takes to strtoll() is unimportant. Don't use configfs/sysfs
for fast-path things.
I disagree. If it's useful for a human, it's useful for a machine.And if it's useful for a machine, a human might want to peek at
it by hand someday to debug it.
Moreover, *fs+bash is a user interface. It happens that bash isNot really. Writing a sane CLI to a binary interface takes
good at processing files, and filesystems are easily discoverable,
so we code to that. But we make it more difficult to provide other
interfaces to the same controls.
about as much work as writing a sane API library to a text interface.
The hard part is not the conversion, in either direction. The hard part
is defining the interface.
Everything is eventually used in the second case, and admin or aConfigfs, as its name implies,Eventually everything is used in the first case. For example in the
really does exist for that second case. It turns out that it's quite
nice to use for the first case too, but if folks wanted to go the
syscall route, no worries.
virtualization space it is common to have a zillion nodes running
virtual machine that are only accessed by a management node.
developer debugging why the daemon is going wrong. Much easier from a
shell or other generic accessor. Much faster than having to download
your library's source, learn how to build it, add some printfs, discover
you have the wrong printfs...
__u64 says everything about the type and space requirements of aAnd if you send the wrong thing to configfs or sysfs you'll get
field. It doesn't describe everything (like the name of the field
or what it means) but it does provide a bunch of boring information
that people rarely document in other ways.
If my program reads a *fs field into a u32 and it later turns out
the field was a u64, I'll get an overflow. It's a lot harder to get
that wrong with a typed interface.
an EINVAL or the like.
It doesn't look like configfs and sysfs will work for you.
Don't use 'em! Write your interfaces with ioctls and syscalls. Write
your libraries and CLIs. In the end, you're the one who has to maintain
them. I don't ever want anyone thinking I want to force configfs on
them. I wrote it because it solves its class of problem well, and many
people find it fits them too. So I'll use configfs, you'll use ioctl,
and our users will be happy either way because we make it work!