linux-kernel - Re: [patch] Move led attributes out of device name and into sysfs attributes, was Re: LED devices

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: <1180712592.6390.139.camel@localhost.localdomain>
Date:	Fri, 01 Jun 2007 16:43:12 +0100
From:	Richard Purdie <rpurdie@...nedhand.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, "kay.sievers" <kay.sievers@...y.org>
Cc:	"Bryn M. Reeves" <breeves@...hat.com>,
	John Lenz <lenz@...wisc.edu>,
	Richard Hughes <hughsient@...il.com>
Subject: Re: [patch] Move led attributes out of device name and into sysfs
	attributes, was Re: LED devices

On Fri, 2007-06-01 at 16:04 +0100, Richard Hughes wrote:
> Patch attached corrects all the brokenness with the led class (encoding
> some attributes in the device handle).

For the benefit of LKML, there has been some discussion of this
elsewhere. My arguments do not particularly come across in Richard's
choice of quoting and I'm a little annoyed he's chosen to do things this
way, particularly before any further feedback from Greg/Kay but so be
it.

Greg said that the LEDs class should export any property data as a class
attribute rather than this just being available in the device name. I
added the patch in
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm to deal
with this, without breaking the existing LED naming and documented API.
Greg said that the only requirement on bus id naming was that it needed
to be unique so this should therefore be compatible. HAL could then go
ahead and ignore the device name, all the attributes are there in the
fashion it needs which was the original complaint.

I accept this is basically out of my hands now. Greg/Kay have the
appropriate emails and if they'll let me know which approach they want
to take, I'll apply an appropriate patch. I'd suggest not applying this
patch directly as it introduces a race in the error path it alters.

Richard

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