New IOCTLs

New IOCTLs

[Singaravelan Nallasellan]

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.

Re: New IOCTLs

[Alan Cox]

On Wed, 17 Sep 2008 22:25:35 +0530
"Singaravelan Nallasellan" <singaravelann@gmail.com> wrote:

> 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.

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

Re: New IOCTLs

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Wed, 17 Sep 2008 22:25:35 +0530, Singaravelan Nallasellan said:
> 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.

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...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: New IOCTLs

[Chris Snook]

Singaravelan Nallasellan wrote:
> 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.

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

Re: New IOCTLs

[Singaravelan Nallasellan]

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.


On Thu, Sep 18, 2008 at 1:42 AM, Chris Snook <csnook@redhat.com> wrote:
> Singaravelan Nallasellan wrote:
>>
>> 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.
>
> 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
>

Re: New IOCTLs

[Louis Rilling]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

On Thu, Sep 18, 2008 at 09:53:51AM +0530, Singaravelan Nallasellan wrote:
> 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.

What about using configfs? A user could create an id using mkdir in the driver'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.

Louis

> 
> 
> On Thu, Sep 18, 2008 at 1:42 AM, Chris Snook <csnook@redhat.com> wrote:
> > Singaravelan Nallasellan wrote:
> >>
> >> 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.
> >
> > 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
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: New IOCTLs

[Chris Snook]

Singaravelan Nallasellan wrote:
> 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.

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.

-- Chris

> On Thu, Sep 18, 2008 at 1:42 AM, Chris Snook <csnook@redhat.com> wrote:
>> Singaravelan Nallasellan wrote:
>>> 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.
>> 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
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: New IOCTLs

[Enrico Weigelt]

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

Hi,

> 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.

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/
---------------------------------------------------------------------

Re: New IOCTLs

[Bodo Eggert]

Louis Rilling <Louis.Rilling@kerlabs.com> wrote:
> On Thu, Sep 18, 2008 at 09:53:51AM +0530, Singaravelan Nallasellan wrote:

>> 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.

> What about using configfs? A user could create an id using mkdir in the
> driver'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.

Sounds like simulating file descriptors, with more overhead and less
functionality, just for having non-atomic access to name->value pairs.

Besides that, we don't yet know the purpose of the IOCTL, and even less about
the driver. Maybe the user will need to read or write, too, or pass the fd
to other processes.