linux-kernel - Re: [RFC] [PATCH 1/2] introduce ALS sysfs class

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

Date:	Thu, 15 Oct 2009 16:54:32 +0100
From:	Jonathan Cameron <Jonathan.Cameron@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	Jonathan Cameron <jic23@....ac.uk>,
	Zhang Rui <rui.zhang@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	Jean Delvare <khali@...ux-fr.org>,
	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	Len Brown <lenb@...nel.org>,
	"Cory T. Tusar" <ctusar@...eon-central.com>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [RFC] [PATCH 1/2] introduce ALS sysfs class

Pavel Machek wrote:
> On Tue 2009-09-22 13:42:23, Jonathan Cameron wrote:
>   
>> Zhang Rui wrote:
>>     
>>> Hi, Jonathan,
>>>
>>> this is the refresh ALS sysfs class driver.
>>> I just introduced one sysfs attribute "illuminance", because
>>> I didn't catch the exact meaning of the others like "???infrared".
>>> So it would be great if you can generate an incremental patch
>>> to introduce the other optional attributes needed, and update
>>> the documentation as well. :)
>>>       
>> Will do, though may just leave it out of first pass of drivers
>> (as it may be controversial and it would be nice to get something
>> in place before the arguments begin!)
>>
>> All looks nice and clean. The only real question is whether
>> we want to standardize naming of devices under sysfs (like hwmon does)
>> or allow the individual drivers to do the naming?
>>     
>
> Allow the drivers to do the naming. Having useless name like "als0",
> with als0/name telling me what the driver is is bad.
>   
This topic came up again in the discussion of the tsl2550 driver port.

Jean Delvare raised a point that I'm inclined to agree with (with several
more ports from elsewhere in the kernel underway).

.... (quoted from [PATCH] ALS: TSL2550 driver move from i2c/chips)

> I'd imaging that als-class devices are simply named als%u. Just like
> > > hwmon devices are named hwmon%u, input devices are names input%u and
> > > event%u, etc. I don't know of any class pushing the naming down to its
> > > drivers, do you? The only example I can remember are i2c drivers back
> > > in year 1999, when they were part of lm-sensors.I have personally put
> > > an end to this years ago.
> >
> > This debate started in the als thread. Personally I couldn't care less
> > either way but it does need to be put to bed before that subsystem merges.
> > To my mind either approach is trivially handled in a userspace library
> > so it doesn't matter.  I don't suppose you can remember what the original
> > reasons for squashing this naming approach were?
>
> Code duplication. Having the same unique-id handling code repeated in
> 50 drivers was no fun, as it did not add any value compared to a
> central handling.
>

So does anyone have a strong objection to moving over the more conventional
als0/ naming and move the id handling into the als core?

Note that unless there is a clear reason for doing it any other way it will
probably meet resistance beyond Jean and myself.

Jonathan




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