>>So you don't recompile, but you still changed the magic ioctl numbers
>>from 17 to 47 and from 18 to 48. Old binaries don't work any more,
>>even though the same semantics are still present. That is an
>>incompatible change in my book.
>>
>>Worse if there is a new semantic for 17 or 18, in that case the old
>>binaries may break randomly, depending on kernel version.
>
>
> Sure but you keep old ones around once its stable. This is a completely
> pointless conversation to have before 2.6.0-test kernels. There isnt a
> stable in kernel dvb api yet because its not been shipped in a stable
> kernel.
>
> (Although I'd note the api has been as stable if not more stable than
> some in kernel stuff 8))
Amen. That's exactly the point -- the v3 dvb api is stable and hasn't
changed for a long time.
So, to make a long story short:
In include/linux/dvb we have the headers that are shared between user
applications and the kernel driver. As I said above, these are stable and
never change for the v3 api. In an ideal world, these header files would
be included in your glibc distribution at /usr/include/linux/dvb
Currently, you must copy them by hand or create a symlink, because there
hasn't been an official kernel with the dvb driver subsystem yet.
The whole discussion was about the *in-kernel* header files in
drivers/media/dvb/dvb-core. These are used in drivers/media/dvb/frontends
for example, so we currently have one line in the Makefile that says to
have drivers/media/dvb/dvb-core in the include path.
This was the original point Sam Ravnborg was wondering about. It's safe to
move these files to inlude/dvb and get rid of the magic line in the
Makefile.
CU
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/