linux-kernel - Re: [RFC PATCH] gpiolib: Provide and export gpiod_export

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: <CAAVeFu+kfJULtfAsHSdSAfro5gxjUFzYZxo1pC7jESFTERtN9A@mail.gmail.com>
Date:	Fri, 29 Aug 2014 10:00:47 -0700
From:	Alexandre Courbot <gnurou@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [RFC PATCH] gpiolib: Provide and export gpiod_export_name

On Thu, Aug 28, 2014 at 10:54 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> On 08/28/2014 10:44 PM, Linus Walleij wrote:
>>
>> On Mon, Aug 11, 2014 at 5:20 PM, Alexandre Courbot <gnurou@...il.com>
>> wrote:
>>>
>>> On Tue, Aug 12, 2014 at 12:15 AM, Guenter Roeck <linux@...ck-us.net>
>>> wrote:
>>
>>
>>>> This is just one of many patches which would make it possible to submit
>>>> the rest, which would make use of it. What you are saying is that it
>>>> won't
>>>> make sense to submit that series into the kernel, because one of the
>>>> very
>>>> first patches needed to enable that won't be accepted. Kind of a
>>>> circular
>>>> argument, but I guess I'll have to live with it.
>>>
>>>
>>> Well I have not seen the other patches you mention and cannot guess
>>> their existence. If you send the full series it will of course be
>>> considered as such, but right now this lone patch does not hint any
>>> upstream user for this interface.
>>>
>>> Note that this doesn't change anything to the core of the argument ;
>>> we have not heard what Linus thinks about named GPIOs in
>>> /sys/class/gpio yet, maybe he will have a different opinion...
>>
>>
>> The sysfs is sort of broken by design because of things like this and
>> some other stuff.
>>
>> I think the sysfs is scary, for example since it's not hierarchical
>> but flat and build on the assumption that there is one single
>> GPIO numberspace. As pointed out in some other message
>> in the thread it would be nicer to have:
>>
>> /dev/gpiochip0/gpio0
>> /dev/gpiochip0/gpio1
>> ....
>>
>> instead of the horrid sysfs ABI that will have to maintain forever.
>>
> Blocking any attempts to make it more useful doesn't help much, though.

This patch is not making it more useful. It just introduces an
inferior way to do something that is already possible.

I have stated it countless times already, but again:
"/sys/bus/.../device/gpio_function" is better than
"/sys/class/gpio/device_function_foo_whatnot" (and actually,
"/sys/bus/.../device/gpios/function" would be even better).

You can already do the former. I just don't see the need to introduce
an API to do the latter.

Why is the former better? Because it uses the sysfs hierarchy to make
the GPIO visible under their consumer's node. That's how sysfs is
intended to be used.

Just explain me why you cannot live with this or why your proposal is
better, and my concerns about this patch will be lifted.
--
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/