linux-kernel - Re: [PATCH 4/4] Added locks for sysfs attributes and internal data.

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:	Sun, 14 Mar 2010 00:42:15 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Stefan Achatz <erazor_de@...rs.sourceforge.net>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Jussi Kivilinna <jussi.kivilinna@...et.fi>, wylda@...ny.cz,
	Pavel Machek <pavel@...e.cz>,
	Alessandro Guido <ag@...ssandroguido.name>,
	Tomas Hanak <tomas.hanak@...il.com>,
	Jason Noble <nobleja@...ezero.com>, simon.windows@...il.com,
	Sean Hildebrand <silverwraithii@...il.com>,
	Sid Boyce <sboyce@...eyonder.co.uk>,
	Henning Glawe <glaweh@...ian.org>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] Added locks for sysfs attributes and internal data.

Hi Stefan,

On Sat, Mar 13, 2010 at 12:19:27PM +0100, Stefan Achatz wrote:
> Hello,
> I have some more questions regarding the work on my driver:
> 
> 1. binary vs text sysfs attributes
> As I found little information about binary sysfs attributes I used the normal 
> sysfs attributes to transfer binary data because they are also easier to use. 
> The transfered data is far less than the 4096 bytes minimum page size.
> So, is there a significant difference in these two variants that should force 
> me to use the binary variant?
> 

I'd say in this case it just sets expectations for the interface -
normal sysfs attributes are supposed to pass data in human-readable
form, one value per attribute.

> 2. memory footprint
> I'm thinking about a redesign of my sysfs attributes to reduce io and simplify 
> the use of binary sysfs attributes (if needed, see above). This would 
> increase the memory footprint of hid_drvdata to around 5kbytes.
> Is it allowed for a driver to constantly alloc such an amount of data or 
> should I stick with more complicated code and more io?

5K is not that much but why do you think binary attributes will require
such increase?

> 
> 3. grow up of driver
> I see my work is not quite ready for kernel inclusion. Maybe I'm wrong in this 
> list and should bug other people. Would the linuxdriverproject.org be a 
> better place to raise my work to adulthood?
> 

Rarely a driver is ready for inclusion right away ;) Normally that
happens after someone submitted a few of them to the same subsystem so
he knows maintainers perferences, etc. I'd say you are doing well as is
here, there is no sense to move away somewhere else at this point.

Thanks.

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