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
| ||
|
Date: Fri, 4 Apr 2008 21:05:47 -0700 From: David Brownell <david-b@...bell.net> To: Ben Nizette <bn@...sdigital.com> Cc: Trent Piepho <tpiepho@...escale.com>, Jean Delvare <khali@...ux-fr.org>, Linux Kernel list <linux-kernel@...r.kernel.org>, Mike Frysinger <vapier.adi@...il.com> Subject: Re: userspace GPIO access (WAS: [patch/rfc 2/4] pcf875x ...) On Thursday 03 April 2008, Ben Nizette wrote: > David, you're kinda the gatekeeper here; any input from you on which > approach is to be preferred, essential features etc? I won't much care about /dev/... vs /sys/... though I'd probably have used sysfs myself (just because it's much simpler and doesn't need to imply mdev/udev and classes). The configuration part of each driver bothers me: - Mike's simple_gpio requires manual kernel config to set up the platform_device nodes ... and thus rules out the first usage scenarios I ever heard of for such a userspace mechanism. - Trent's gpio_class exposes all GPIOs, even ones that are claimed by kernel drivers ... and thus makes it easy to clobber kernel driver state. (Plus it won't work on most built-in GPIOs, since they by and large don't have parent devices.) What I'd like to see is userspace config commands to cause the gpio_request() ... *maybe* something like echo 42 foo 0 > .../gpio_config ... causing error-checked versions of: gpio_request(42, "foo") gpio_direction_output(42, 0) ... then some .../gpio42 file, read/write, appears and echo 84 bar in > .../gpio_config ... causing error-checked versions of: gpio_request(84, "bar") gpio_direction_input(84) ... then some .../gpio84 file, read-only, appears Though arguably the label could just always be "userspace" (it's mostly for /sys/kernel/debug/gpio), and the default could be to configure as an input (unless an output value was given). Plus, there should be some way to cause gpio_free() too. A potential advantage of the /dev/... node approach would be that it's easier to support an IRQ-backed poll() mechanism for inputs. - Dave -- 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