Re: New IOCTLs

[Chris Snook <csnook@redhat.com>]

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/