They would be different releases of v1 and would be functionally equivalent. It would just be another v1 release - the ends user has no need to know which GPIO uAPI is being used behind the scenes. It would just mean that the packagers could start bundling a kernel without the v1 uAPI.Perhaps not but as I understood it there would be a v1 using v1 API and a v1 using v2 API but both would likely get called 'v1' by users with no indication of which API is being used which would make things rather confusing in my book if both 'v1' had different functionality or capabilities.
It just seems it's simpler and less confusing to have v1 use the v1 API and v2 use the v2 API.
Just like all the sysfs users enthusiastically adopted the uAPI?They move to v2, as they would have to if an intermediate v1 didn't exist.
Firstly, we considered extending the libgpiod v1 API to support uAPI v2 features, but the v1 API was already overly complicated and that just made it explode.Or v2 could be made backwards compatible with v1 and v1 users would not have to care whether the underlying stuff which implements what they call is v1 or v2.
So, as with the uAPI itself, it was time for a complete re-write. v2 is cleaner and simpler and, unlike v1, has been designed so it can be extended without breaking backward compatibility.
Supporting both APIs in the one C library makes no sense. You then have one library that provides two very different APIs to end users who only want one or the other. It is literally the same as providing two separate libraries in the one library, bloating it for all users.
The packagers can include both v1 and v2 libraries in their distros if they want. Or either. Keeping them split provides more flexibility and no downside to the end user.
The kernel and libraries tend to prioritize "safe and correct" over "fast and loose". So more like your bank than your girlfriendThe way I see it is that 'libgpiod' has been designed to enforce sole ownership of I/O signals and that's perfectly fine for a system where ownership is used to protect one thing from another but it doesn't suit embedded use where makers play more fast and loose in what they do. For example wanting to have multiple apps read the same input button or set or clear the same output.
. And makers aren't their only audience.You continue to conflate libgpiod and the uAPI. The access restriction comes from the uAPI, and it is there because there are cases where it is required. It also keeps the kernel simple, as otherwise it has to provide some complicated access control mechanism, so more code and a bigger more confusing interface. Sharing of the line, and providing whatever level of access control is appropriate, can be performed by userspace and is best done there.
Wrt outputs, having multiple apps driving the same GPIO line is poor design at best. It is lazy, sloppy, racy, error prone and, depending what that line is connected to, potentially dangerous. Break that bad habit. Make one component responsible for the line and have the others communicate with it. That component can provide access control, or not, as you see fit.
Alternatively, it may be appropriate to use a kernel module like leds-gpio that provides an interface with less restrictive access.
Wrt inputs, the edge event provided by the uAPI are superior in every way to what the sysfs interface provided. The uAPI edge events, which provide details including an accurate timestamp, are buffered in the kernel and provided to userspace as a sequence. But you can't have multiple readers of that sequence, so if you want fanout then you need to provide that in userspace. And it isn't that hard to do - in this thread I wrote a fast and loose example that piped the output from gpiomon into a file where other apps could monitor it.
"embedded" is something that does not interact directly with users. That may be running Linux, or it may not. It depends.
What you call "embedded" is closer to what I would call "bare metal" - where you have no OS and are accessing hardware directly, and basically have full control and can do whatever the hell you like. But here you are running Linux so that isn't the case - the kernel is managing access to the hardware. And that is necessary as otherwise there can be concurrent accesses causing race conditions (unless you are an extremely advanced user and emulate bare metal by disabling the kernel drivers and manage ALL access yourself - but no one in the Pi space is suggesting that). If you want bare metal then use a microcontroller that doesn't run Linux, like the Pico.
The problem, as I see it, is that the Pi running Linux has been sold to makers AS a microcontroller. Up until the introduction of the Pi5 you could treat it as one and for the most part get away with it. But it never really was, and the Pi5, which offloads the GPIOs to a separate microcontroller, has just made that clearer.
I've already provided this link - it in the master branch of libgpiod and is slated to be part of the v2.2 release.If there is some daemon in the pipeline which provides access control so I/O signals can be restricted for kernel, OS, sole user, shared or unlimited use that will be great but it doesn't currently exist as far as I can tell.
You can build it and play with it now if you want. Feedback is always welcome, and more useful BEFORE it gets released. Once it gets released things are pretty much set in stone, at least until the next major release.
It provides unlimited access, IIRC, to the lines it has requested, though of course it won't be able to request a line already requested by another app or the kernel.
Hmmm, though now I think about it, the glib bindings that the daemon uses require a version of glib more recent that that available in Bookworm. IIRC I had to build and test it using a Debian testing image.
Statistics: Posted by warthog618 — Wed Oct 16, 2024 3:55 am