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]
Message-ID: <20100314084215.GA8226@core.coreip.homeip.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ