search

eclipse / mraa

Linux Library for low speed IO Communication in C with bindings for C++, Python, Node.js & Java. Supports generic io platforms, as well as Intel Edison, Intel Joule, Raspberry Pi and many more.
http://mraa.io
MIT License
1.37k stars 614 forks source link

using new chardev access for gpios in new kernel #713

Open Mani-Sadhasivam opened 7 years ago

Mani-Sadhasivam commented 7 years ago

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

arfoll commented 7 years ago

This makes a lot of sense, please go ahead :)

Mani-Sadhasivam commented 7 years ago

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?

bjbeare commented 7 years ago

Can presence of the node act as the switch?

Mani-Sadhasivam commented 7 years ago

It can! Just want to know whether to stick with static detection or dynamic :) Will stick with dynamic detection

arfoll commented 7 years ago

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...

Propanu commented 7 years ago

@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.

RobertBerger commented 6 years ago

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/

bjbeare commented 6 years ago

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.

RobertBerger commented 6 years ago

@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.

bjbeare commented 6 years ago

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.

Mani-Sadhasivam commented 6 years ago

@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!

arfoll commented 6 years ago

@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.

Mani-Sadhasivam commented 6 years ago

@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!

Mani-Sadhasivam commented 6 years ago

@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...