linux-kernel - Re: New IOCTLs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 19 Sep 2008 15:22:31 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Singaravelan Nallasellan <singaravelann@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: New IOCTLs

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@...hat.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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