On Thu, Feb 26, 2015 at 11:27 AM, Alexandre Courbot <gnu...@gmail.com> wrote: > On Fri, Feb 20, 2015 at 1:52 AM, Linus Walleij <linus.wall...@linaro.org> > wrote: >> On Thu, Feb 19, 2015 at 9:53 AM, folkert <folk...@vanheusden.com> wrote: >> >>> I also think that this interface is cumbersome. I did not measure it(!) >>> but I think adding this open/seek + read construction may add all kinds >>> of overhead. Especially since my use-case requires the lowest latency >>> possible. Not to forget that conversion of the measured value to ascii >>> and back. >> >> Yes this interface sucks. >> >> The tentative long-term plan is to replace it with something like >> a char device that can handle a quick context switch and also >> issuing calls to set multiple pins at once, as we now have an >> in-kernel interface for that (that I totally refuse to support from >> sysfs). > > Mmm, I was thinking it would be nice to have a (new, redesigned) sysfs > interface for this. :P > > Aren't we going to make things less accessible if we use a char device?
Since sysfs has a "one value per file" paradigm, it also has a "one context switch per operation" paradigm, meaning any efficiency-oriented use cases where a lot of stuff needs to be changed in one context switch are by the very construction not suitable for sysfs IMO. That is the use case for ioctl() operations that can pass an entire struct of stuff over. And things like bit-banging a clock+data line which would in a sysfs case involve two context switches (one per value, since that is one file per GPIO line) in an ioctl() case it would be just one, already 50% less context switches for a very basic use case. But I may be just so wrong ... input welcome. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
