GPIO Configuration Checking in jdk.dio

[Sergey Nazarkin]

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