This library wraps the kernel interfaces directly, and currently doesn't try to do much more than be relatively thin but still safe wrapper for /dev/dvb devices.
The primary objectives for this library is to get frontend and demux devices working. CA support and DVB network support are secondary at the moment, but as the APIs seem relatively simple to wrap in a similar way than the frontend and demux APIs, they probably can eventually be added too. There's no intention to support the deprecated video and audio device APIs. Deprecated parts of the API are left out from other parts too.
This library relies heavily on generated code. The lower FFI part (this library is pretty much an FFI wrapper, but I mean the lower level part of it here) is generated by rust-bindgen, and that part is not done as part of the build. First reason for this is that if bindgen had to run at every build, every machine building the code would have to have the required headers. They probably aren't that rare (on Debian they come from linux-libc-dev which isn't particularly esoteric package), but it's nicer to depend only on Rust stuff. The second reason is that at least on Debian, rust-bindgen doesn't work out of the box at the moment. Thirdly, the header doesn't seem to live all that much.
The bindgen codegen is implmented/documented as a bash script that does some nasty trickery under the codegen/bindgen directory.
Under the codegen directory there's also enums subdirectory, that has a build script which generates a bunch of enums. Rust-bindgen generates only the bare necessities for FFI (and that's pretty much its job, not more), so the constants are combined into enums and helpers to convert them to the integer equivalents and back. Even though the raw generator code lines/generated code lines ratio is not very good, the generator code is mostly just lists of constant names that in some cases expand to several lists (the enum and match statements for the enum). I believe this approach has less tedious, repetitive coding and therefore less chances for causing subtle copy-paste-bugs.
The high-level codegen is centered around the frontend properties, implemented as enums in the Rust code. The API takes a list of property names or name+value pairs and either returns the values (as a Vec) or sets the properties, respectively. While the V4L API isn't completely explicit about this, in practice some of the properties are essentially read-only, meaning there's no meaningful way of setting the said properties. The most obvious example of these are the statistics properties that can be read but not set. This library exposes only the gettable and settable properties that are actually gettable or settable. The list of those properties are figured out by looking into the kernel code. (See dtv_property_process_get and dtv_property_process_set in dvb_frontend.c to see the properties.) This is risky in a sense, but here too I believe, as was with the header files, that the API is quite stable at this point, so this doesn't seem to be too bad of a choice.
As the code has evolved, the code generation is used for Demux device related enums too. At the same time, the codegen has been modularized into frontend-specific, demux-specific and common parts. However, the frontend properties are still definitely the most complex part of the codegen.
Documentation is lacking at the moment, but as the library looks very much like the actual API it is meant to wrap, you can use the official documentation with this library too: http://linuxtv.org/downloads/v4l-dvb-apis/dvbapi.html
Apache 2.0. See LICENSE for full information.
The files generated by rust-bindgen do not have the copyright notice, and it's possible they aren't even copyrightable (at least by me, or as part of this library), being created by a tool from a file originally created by Linux developers. I also explictitly do not want to meddle with the contents of those files. However, the generated files should also be considered to be under the same license to the extent it is possible.