Add mappings for Udev Library.

[dbwiddis]

See references here.

[matthiasblaesing]

The bindings looks sane to me. Looking at the API I'm thinking, that this is basicly a OO model. This might be an optional enhancement (not finished, but should give the idea):

matthiasblaesing@ba02d6b

[dbwiddis]

Great idea. I'll update. One thing to note, the docs specify return types for both the *_ref() and *_unref() functions: ref returns the unmodified object and unref "always returns null". I do agree with changing the unref return to void (since testing shows it doesn't actually return null as advertised) but I think the ref version should return this;.

[dbwiddis]

Hmm, I expect the "double-free" is me trying to release parent reference. This doc is confusing but I suppose it means "don't unref it"...

On success, udev_device_get_parent() and udev_device_get_parent_with_subsystem_devtype() return a pointer to the parent device. No additional reference to this device is acquired, but the child device owns a reference to such a parent device.

[dbwiddis]

Sorry for the 8 or 9 force pushes. The good news is my own appveyor setup is pretty strict on javadocs. The bad news is that it was killing the build too quickly for me to see the errors in the logs and I kept finding and fixing a few at a time. It should be good to go now.

[matthiasblaesing]

This is not correct - the definition needs to match the C version. I dropped the return in my suggestion for the OO binding - but only on the java level, not on the Java<->C interface level. Depending on how the return value is returned, memory might need to be reserved for this. If it does not happen, strange issues could result, so please return the UdevContext here.

The same is true for all callsites, where Structure was turned to void.

[dbwiddis]

Gotcha, I missed that subtle distinction.

[matthiasblaesing]

Merged - thank you