GPIO Configuration Checking in jdk.dio
Sergey Nazarkin
sergey.nazarkin at oracle.com
Wed Jun 4 09:50:46 UTC 2014
Hi Jen,
Yes, this is consistent with what I'm seeing. All pins not reported
error are available for applications running on Linux and quite safe for
use. However not all of them are useful just because are not wired to
any place on the board. And some of them can result in kernel crash but
root of crash would be board design, not chip core. And this is what
distinguish embedded world from desktop. Embedded developer should be
more careful with BOARD resources, not only CHIP. There are many way to
shoot at own feet and DIO is not the only. There are sun.misc.unsafe,
and native libraries, and bunch of other dangerous methods. We can't
guard app developer from all them. So we need to demarcate a regions
of responsibilities. I believe DIO is only generic API that
interconnects Java app and native resources. And it is not our business
to prevent application to do some thing that may be dangerous for only
one board revision.
/Sergey
04.06.2014 1:39, Jen Dority пишет:
> Hi Sergey,
>
> Sorry for the spam. I got the mailing list address wrong the first
> time. :)
>
> I wanted to continue this discussion on the open mailing list since
> it's finally up-and-running.
>
> I did some testing on the raspberry pi with the GPIO pin "validation"
> code removed from the native layer.
>
> With this custom build, I then tried to open and write to each
> possible GPIO pin from 0 to 27.
>
> Of the 28 test cases, only 1 (GPIO16) caused an error to be reported
> back from the OS calls -- although messing with GPIO6 did BAD THINGS
> and is not recommended. This is far fewer errors than I expected.
>
> Is this consistent with what you are seeing? Did you need to add more
> error checking to gpio.c to rely on the gpio driver to keep users from
> opening (and writing to) GPIO pins that weren't really available?
>
> I understand what you're saying about it not being our code's place to
> do this kind of checking, but it doesn't look like we get much of any
> checking from the sysfs API.
>
> Jen
More information about the dio-dev
mailing list