I need to send device control messages to the driver. I am planning to
use the IOCTLs. But I came to know that Linux community does not
accept any new IOCTLs anymore.
Can somebody provide the reason behind the decision? Are there any
better approach to implement the device control interface other than
sysfs interface. I have some issues in using the sysfs interface.
Thanks in advance.
--

[ message continues ]

On Wed, 17 Sep 2008 22:25:35 +0530

I don't know who told you that but its not true.
--

[ message continues ]

New IOCTL's are *not* in the "not accepting any new" state.  However, there
*will* be questioning whether a new IOCTL is the proper API, or if there
should be some other interface instead (sysfs, debugfs, netlink, and so on).

The basic problem with IOCTLs is that they tend to quickly become ugly design,
with little attention paid to things like proper 32/64 bit interfaces (what
happens when a 32-bit program tries to pass a parameter to a 32-bit
kernel, and to a 64-bit kernel?).

Maybe an ioctl is the right way to send your device control messages. Maybe
some other API is better.  What sort of messages need to be sent, and what
sort of throughput/latency requirements are there, and so on?  If you tell us
more about what you're trying to get to/from userspace and the device, we
can better suggest what to do...
[ message continues ]

IOCTLs are discouraged, but not strictly forbidden.  Is there something about 
sysfs that would make it an unsuitable interface, or are you just having trouble 
finding good documentation on using it?

-- Chris
--

[ message continues ]

Thank you for your response.

The driver needs to assign an id for each open and create a sysfs
entry based on that id and expose some properties.

For example, if the driver assigns an id 2, the sysfs entry will be as below:
/sys/class/xxx/<drivername>/2/version

When the driver close is invoked, it will have to remove the entry.

The issue here is that the application needs:
1. To know the id it should use to access properties after the open.
2. To have exclusive access to the sysfs entries. No other application
should and open the entry and use it. There is a chance the the other
application could open the entries before this application opens it.

The driver allows multiple opens and assigns any random id.

I appreciate your suggestion on alternate ways to implement the functionality.


--

[ message continues ]

lity.

What about using configfs? A user could create an id using mkdir in the dri=
ver's
configfs subsystem, and this would make the driver create the matching sysfs
entry.

# mkdir /sys/kernel/config/<driver_subsys>/2
-> reserve id 2 for the caller, and create /sys/class/xxx/<drivername>/2

You could even put whatever configuration items inside configfs instead of
sysfs.


--=20
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes
[ message continues ]

If you really need for each file descriptor that opens your device to have a 
unique context and set of properties that may be different from the rest, then 
an IOCTL might be legitimate here.  If the device behaves the same way 
independent of context, then it's really just a locking issue, sysfs is the way 
to go.


--

[ message continues ]

* Singaravelan Nallasellan <singaravelann@gmail.com> wrote:


Simply add an clone file, reading from it creates new context and 
sends back its ID.

box:/ # cat /sys/class/xxx/foodriver/clone
3

box:/ # cat /sys/class/xxx/foodriver/3/version
1.0

...

To destroy the context:
box:/ # echo "release" > /sys/class/xxx/foodriver/3/ctl


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
--

[ message continues ]