I'm not sure we are talking about the same thing.I think that would make things even more confusing than they already are. And I am not convinced it would make life any easier for those producing distros than providing whatever is needed to allow them to deliver a pure 'v2' solution.
My priority is what makes life easier for end users. Those producing distros are a secondary consideration.
The issue with a "pure 'v2' solution" is what happens to existing v1 users?
I don't see how it would cause any confusion as the change would be invisible to both users and packagers. The only difference being the underlying kernel API used and so the minimum kernel version required, so 5.10 or later. But I'm just ruminating here - it isn't as though there are any plans to remove the old uAPI from the kernel any time soon and there is zero benefit until that is at least on the horizon.
By "making what there is more suitable for embedded use", what do you need?We do need some way of knocking the square peg into a round hole, making what there is more suitable for embedded use, but I am not sure how that should be done. My feeling is it would be better if 'libgpiod' supported what was required rather than having to layer something else on top to make it do what is needed. But, as a means to the end, I would be in favour of it. The issue also extends beyond command line use.One thing I have wondered about is whether our users would benefit from having a daemon to own the GPIOs on their behalf for the cases where they are interactively tinkering on the command line.
When you say 'libgpiod' do you mean the userspace library (which is what that name refers to) or do you mean the kernel GPIO uAPI? There is a daemon coming for libgpiod. Even entertaining changing the uAPI would require a definition of "make it do what is needed" as that statement is a tad vague. Again, what do you need, and why can't it be solved in userspace using the existing uAPI?
Statistics: Posted by warthog618 — Mon Oct 14, 2024 1:10 pm