On Fri, Oct 30, 2015 at 08:47:14PM +0100, Linus Walleij wrote: > On Fri, Oct 30, 2015 at 2:55 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: > > * For all the justified hate that sysfs got, it had the advantage of > > being directly accessible using only the shell. If we replace it with > > a character device interface, I think we will need a "libgpio" (that > > provides easy access to C programs) and "gpio-tools" (simple > > command-line tools that provide functionality similar to the sysfs > > interface). Are we ready to start and maintain these? Granted, it > > should not be too much work, but it's still an extra. > I think the raw ioctl()s will be simple enough and intend to use > the tools/gpio/* as proper examples. If we need > tools/gpio/swiss-army-knife.c we will add it too. > ALSA and fbdev and MESA and libusb spawned huge userspace > libs, but I hope this ioctl() ABI will be simple enough that apps > can use it directly without a lib. But what do I know. That only works for very C like languages, for other languages (things like scripting languages in particular) you're going to need a library for the language to bind to in order to be usable. > > How these will be shaped will of course depend on how individual GPIOs > > are represented in user-space. Security will be a concern, so let's > > make sure we don't return global integer descriptors for these. ;) > First-come-first-gets-to-use-it seems to be how chardevs etc > are handled. I imagine there will be ONE program using the gpiochip, > else userspace have to come up with an arbitration daemon too. That's another thing pointing to a library then...
Attachment:
signature.asc
Description: PGP signature
