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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux