[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: a common DVB infrastructure
Manu Abraham wrote:
About myself: i do some freelance development with regards to DVB, as of
till date it has been with regards to Linux-DVB as a whole.
Welcome Manu, and thanks for your interest in NetBSD!
I do write this post in the regards that a cross platform DVB API can
exist, which can be used under other platforms as well.
This platform should eventually be backward compatible for existing
I do understand that, for an older system it can be made practical to
have a compatible layer to do a translation. But in the case of a newer
system, there will be newer parameters etc.
In such a case, in the case of a newer system, what about the usability
with existing applications, as they need to select something new.
In the case of older systems, i was made aware that proplib is used with
BSD with a key-tag approach which sounds practical. In the case of Linux
this is not available. As far as i have asked people around they do not
prefer a library to interface with the kernel IOCTL's but would like to
use the ioctl's directly. This has been seen with the ALSA driver
subsystem under Linux, where people do hate that userspace library.
This is one case where i am lost.
I think comparing proplib to the ALSA libraries is unfair. In this
situation, proplib merely manages encoding and decoding messages, in
essence a wrapper around ioctl. From the application writer perspective
instead of reading back say a "struct dvb_mumble", you would receive a
prop_dictionary_t that you can query. Likewise, to send data to the
kernel, you simply create a prop_dictionary_t and fill it in.
Another aspect is the area where the GPL vs BSD licenses do clash.
For example some vendors (hardware manufacturers) do state the work
being done with their support be GPL'd. This happens to exist for some
new drivers that i happen to work upon.
GPL drivers can be made functional, with a few caveats:
1. We (or people who use NetBSD as a base for their own systems)
cannot distribute binaries that include your GPL'd device drivers.
This is a restriction of GPL, not our license.
2. We could theoretically ship source-only drivers, but that is only
really useful for end users of our system.
To achieve end-user support these drivers could be shipped as kmods, but
at the end of the day I think the best approach is to have talks with
these vendors and ask them to reconsider.
Main Index |
Thread Index |