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:	Thu, 18 Sep 2008 11:11:07 +0200
From:	Louis Rilling <Louis.Rilling@...labs.com>
To:	Singaravelan Nallasellan <singaravelann@...il.com>
Cc:	Chris Snook <csnook@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: New IOCTLs

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

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

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ