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>] [day] [month] [year] [list]

Message-Id: <E1KgKu7-0003nd-E6@be1.7eggert.dyndns.org>
Date:	Thu, 18 Sep 2008 16:54:47 +0200
From:	Bodo Eggert <7eggert@....de>
To:	Louis.Rilling@...labs.com, Chris Snook <csnook@...hat.com>,
	linux-kernel@...r.kernel.org,
	Singaravelan Nallasellan <singaravelann@...il.com>
Subject: Re: New IOCTLs

Louis Rilling <Louis.Rilling@...labs.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.

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