Open Mani-Sadhasivam opened 7 years ago
This makes a lot of sense, please go ahead :)
How should we distinguish the kernel version for implementing switch (sysfs/chardev)? It will become very hard if the library is cross compiled. So, uname won't work! env variable maybe?
Can presence of the node act as the switch?
It can! Just want to know whether to stick with static detection or dynamic :) Will stick with dynamic detection
Dynamic detection is the best and is in keeping with how mraa generally works. My recommendation would be to check for the kernel version first and then if kernel looks like it could have the chardev node then try access it.
Then we can add some cmake options to disable one or the other modes.
FYI please add this as a full implementation inside src/gpio.c as src/gpio_chardev.c and src/gpio_sysfs.c rather than just making src/gpio.c too big and make src/gpio.c just the code that is the same for both/malloc of the _gpio context etc...
@arfoll what's your take on adding char* device paths to all the MRAA I/O structs (incl. GPIO)? It seems like that's one of the things we want to easily customize, but I haven't considered the performance/size hit.
Just a stupid question:"What don't we build on top of libgpiod?" [1]
"Since linux 4.8 the GPIO sysfs interface is deprecated. User space should use the character device instead. This library encapsulates the ioctl calls and data structures behind a straightforward API."
I somehow get the feeling that things are re-invented here.
[1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
The base kernel support requirement for Android Things is 4.4.
From: Robert Berger [mailto:notifications@github.com] Sent: Monday, December 11, 2017 12:59 PM To: intel-iot-devkit/mraa mraa@noreply.github.com Cc: Beare, Bruce J bruce.j.beare@intel.com; Comment comment@noreply.github.com Subject: Re: [intel-iot-devkit/mraa] using new chardev access for gpios in new kernel (#713)
Just a stupid question:"What don't we build on top of libgpiod?" [1]
"Since linux 4.8 the GPIO sysfs interface is deprecated. User space should use the character device instead. This library encapsulates the ioctl calls and data structures behind a straightforward API."
I somehow get the feeling that things are re-invented here.
[1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/intel-iot-devkit/mraa/issues/713#issuecomment-350856212, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABIn9Uzyh7V6yQ5FX4dEXYl2pQWEIF_fks5s_ZeVgaJpZM4NKhLK.
@bjbeare Now I am even more confused. In this thread we are NOT talking about 4.4 and also NOT about whatever Android Things uses. It's about the new chardev access for gpios.
Perhaps I should have phrased my comment as a question...
Is there a version of libgpiod that works well with a 4.4 kernel that has no backports to support it?
From: Robert Berger [mailto:notifications@github.com] Sent: Monday, December 11, 2017 1:22 PM To: intel-iot-devkit/mraa mraa@noreply.github.com Cc: Beare, Bruce J bruce.j.beare@intel.com; Mention mention@noreply.github.com Subject: Re: [intel-iot-devkit/mraa] using new chardev access for gpios in new kernel (#713)
@bjbearehttps://github.com/bjbeare Now I am even more confused. In this thread we are NOT talking about 4.4 and also NOT about whatever Android Things uses. It's about the new chardev access for gpios.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/intel-iot-devkit/mraa/issues/713#issuecomment-350862115, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABIn9cUdK7BMq2Cv3CjIIAobdAFLeo28ks5s_ZzvgaJpZM4NKhLK.
@RobertBerger So the issue is Licensing. The day when I started to work on this support, libgpiod
was licensed under GPL v3 and now it has been changed to LGPL v2.1+. So, @arfoll didn't favour dependency with the incompatible license and that's why this whole reinvention came up.
One interesting thing about libgpiod
is that it has grown from a normal userspace tool to a well structured library now!
@Mani-Sadhasivam is right, it was mostly driven out of the license. GPLv3 was a not appropriate for us, LGPLv2.1 is ok but still not as open as we'd usually like.
I don't really see it as re-invention, chardev is a public kernel API and frankly it doesn't take that much code to use it. Mraa is meant as a low level library and so tries to limit it's dependencies. And yes libgpiod is a nicely structured lib now but is still relatively new, we'll watch how it evolves and may come back on that decision.
@arfoll Any update on this? It might be better to switch to new Chardev interface quickly. Lemme know if you need any kind of help from me!
@arfoll Just realised that most of the 96Boards platforms got upstream support and they will be running close to mainline. Which means, sysfs way of accessing GPIO's won't work anymore. This is due to the fact that the GPIO base will be set dynamically by the gpiolib core and we can no more map GPIOs using global number space and the only resort is to use Chardev interface.
Please consider Chardev merge as a priority work if possible...
In kernel 4.7, new chardev access has been added which allows the userspace to access the gpios in an efficient way compared to sysfs interface.
There is already a library available (https://github.com/brgl/libgpiod). So, I'd like to add support for this new way of accessing gpio in libmraa for kernels > 4.7