Re: 26 ways to set a device driver variable from userland

Kyle Moffett
2005-10-19T17:34:57Z

On Oct 19, 2005, at 13:00:45, Rick Niles wrote:
> There are so many ways to set a configuration value in a device
> driver. I'm wondering which are "recommended" methods. I'm looking
> for some sort of guidance when writing a new driver. I kinda
> assume this is a FAQ, but I didn't see it anyway, maybe it should
> be added to the FAQ.
>
> OK there might not be 26 ways, but there's a few major ones. I'm
> thinking in term of char devices so some of these might not apply
> to block and network drivers.

I'm going to kind of try to summarize a lot of the comments I see on
this list in general here; I may get some of the fine points wrong,
but you should be able to get the gist of things.

> (1) ioctl, probably the oldest.

New ioctls are frowed upon, mainly because they tend to involve
fragile binary structures that aren't very 64-bit compatible. It's
possible to avoid those issues, but sufficiently difficult that I
would recommend against ioctls.

> (2) use read/write to a special configuration-only /dev file (e.g. /
> dev/dvb)

This is similar to the above with ioctls, except using read() and
write() instead of ioctl() on the device. I don't recommend it for
similar reasons.

> (3) /proc filesystem

/proc is for processes, not hardware. There is some stuff in there
that shouldn't be (/proc/bus/usb), but it's slowly being moved out,
so don't introduce new stuff.

> (4) sysfs

This is ideal for almost all device driver purposes. It's really
easy, integrates well into the device model, trivial to configure
from hotplug scripts which already have sysfs path info associated
with them, etc. The idea behind sysfs is to have small single values
broken up into human-readable and human-useable pseudo-files. Some
random PCI device would have various little configuration values and
strings, dma mode configuration, useful human-readable numbers and
text pulled from the PCI ROM, a binary dump of PCI config space and/
or firmware for debugging, etc.

> (5) module load-time command line options.

These are nice and relatively easy to use, but cannot be changed at
runtime on their own (If they have a corresponding sysfs file, then
they can, however). Sometimes that's appropriate, but usually you
want a more flexible solution.

> Should EVERY variable that can be modified by say sysfs also be
> settable by insmod command line?

I wouldn't recommend it. Frequently such sysfs files are device-
specific.

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
-- Alan Kay