Messages in this thread | | | Date | Thu, 26 Jun 2003 10:18:49 +0200 | From | Michael Hunold <> | Subject | Re: DVB Include files |
| |
Hello Alan and others,
>>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/
| |