Linux driver: ioctl or sysfs?

Question

I'm writing a driver to control some custom hardware.

In the old days (i.e. 15yrs ago) I was doing this with ioctls, but am now digging into sysfs as a possible alternative.

• As I understand it, ioctls aren't totally deprecated, but sysfs is preferred (?)
• I need to read/write sets of values simultaneously i.e. through one sysfs entry. I've read that this isn't ideal, but is acceptable if necessary (?)
• There needs to be 'mutex' protection on the driver, so that only one app can write to it at a time. (I do have some read-only 'info' entries which I'd prefer to keep accessible to all at all times).

Given the above, what would be the best way to proceed - ioctl or sysfs?

If sysfs, then how can I implement exclusive access?

If sysfs, then if the driver has no read/write/ioctl fops, does it need open/release?!

(This is a 'private' driver, so I don't care massively ;), but figured if the new ways are more applicable then I might as well get to grips with them!)

Thanks.

Answer 1

I will try to at least partly answer your question. Feel free to comment to ask me to expand (or shrink!)

• First of all, these days ioctls are no longer considered deprecated, as people haven't found better solutions to all the problems they solve. People are expected to be more disciplined defining ioctl interfaces though, and to truthfully express what they will read and write in the ioctl number encoding if at all possible. ioctls and sysfs have different strengths.
• sysfs is mainly useful for exposing particular attributes of devices to user space, particularly to a user on the console or a shell script, and letting those attributes or device configuration be changed. A single sysfs file usually maps to a single attribute and is usually readable (and/or writable) as a simple text string. For example it might expose the current power management state of a device (e.g. "Off") and let you write a new one using the "cat" shell command.
• sysfs is indeed not tied to an open/release session (and you should not have to implement those to use it), so it is probably only really suitable for global attributes. Should not be a problem if the user is only expected to be performing a single operation on the device at a time, but makes it harder to enforce (so probably not ideal for your "sets of data simultaneously", unless you encode them all into one string). And yes, you want to protect any driver data you will access from your sysfs handlers with mutexes, probably one mutex per logical set of data (or one for several logical sets).
• ioctl is better suited to passing binary information between user-space and the driver, and needs a C programme or similar to use it. Custom ioctls are well-suited to writing a minimal driver in the kernel and putting logic in a matching user-space programme. Unlike sysfs it doesn't need extra logic for interpreting text strings - it can read and write data straight from the user process memory - which means less unnecessary code, but also more opportunities not to safety check the data thoroughly.