linux-kernel - Re: [patch/rfc 2.6.25-git] gpio: sysfs interface

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:	Tue, 29 Apr 2008 22:35:26 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	Trent Piepho <tpiepho@...escale.com>
Cc:	David Brownell <david-b@...bell.net>,
	lkml <linux-kernel@...r.kernel.org>,
	hartleys <hartleys@...ionengravers.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	Bryan Wu <cooloney@...nel.org>
Subject: Re: [patch/rfc 2.6.25-git] gpio: sysfs interface

On Mon, 2008-04-28 at 22:48 -0700, Trent Piepho wrote:
> On Mon, 28 Apr 2008, David Brownell wrote:
> > On Monday 28 April 2008, Trent Piepho wrote:
> >> On Mon, 28 Apr 2008, David Brownell wrote:
> >>> Simple sysfs interface for GPIOs.
> >>>
> >>>    /sys/class/gpio
> >>>        /gpio-N ... for each exported GPIO #N
> >>
> >> I liked it better they way I had it, "label:N".
> >
> > Those labels may not be available though; or valid in pathnames.
> 
> So just fall back to "gpio" if there is no label?  The only character that's
> not valid in a pathname is '/', so that's trivial to check for.
> 
> const char *label = chip->label && !strchr(chip->label, '/') ?
>  	chip->label : "gpio"; /* or "generic" or "unknown", or ...*/
> 
> This means you don't need a file with number to device assignents.  It makes
> shell scripting a lot easier too.  Say I want the first gpio on a pca9557 gpio
> expander?  It's will be something like:  /sys/class/gpio/pca9557-0:0
> 
> You don't have to worry about dynamic assigments.  You don't have to resort to
> convoluted shell script code to extract the proper range from a mapping file
> and then construct the name.

Sorry if I'm being dense; how do you want this bit to work?  As I see
it, there are a few options:

1) Have the files named as you suggest and all of them always present,
albeit read-only until export.  Very easy to use, easy to discover which
file is which, a decent bit of memory usage having them all listed.

2) Have the files named as you suggest and you have to explicitly
request them or have the kernel explicitly export them.  To request them
yourself you're going to need the gpio number so having the created file
labelled nicely isn't a win over having it labelled with the gpio
number.  I 'spose there's a win for kernel exported gpios, they're more
human readable, but you're still going to have to have the mappings
available somewhere for the manually exported gpios anyway.

3) Have the files named as you suggest, explicit export/request but
better parsing behind the control file so something like
echo "export pca9557-0:5" > control
works.  Very very nice for the user, big heavy back end.

4) Status quo.  Easy, efficient, potentially hard to discover which gpio
you actually want.

My vote's for 1 or 4.  The first one is heavier but easier.  The last
one will need something like the discussed file mapping ranges to gpios.
Do your expectations/ideas fit in cleanly anywhere above?

Thanks,
	--Ben  

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