DVB Include files
Hi Michael.
I can see that dvb has header files present in:drivers/media/dvb/dvb-core
The usual rule is that header files used by others shall be located in include/linux/..., in the dvb case is must be:include/linux/media/dvb/
Any particular reason to keep them in the dvb-core dir?
hch: Please correct me if I got it wrong with respect to include files.
Sam
Quoted 1 line · Sam Ravnborg
hch: Please correct me if I got it wrong with respect to include files.
I don't think it makes sense to have includes outside the current directory if it's never used from somewhere else. Otherwise I'd move it to include/linux/ (for one or two headers) or include/<subsystem>/
Quoted 6 lines · Christoph Hellwig
Quoted 1 line · Sam Ravnborg
hch: Please correct me if I got it wrong with respect to include files.
I don't think it makes sense to have includes outside the current directory if it's never used from somewhere else. Otherwise I'd move it to
include/linux/(for one or two headers) or include/<subsystem>/
For the dvb case, the .h files are used by files located in:
dvb/frontends
dvb/ttpci
Therefore I suggested linux/media.
For files such as drivers/scsi/aic7xxx/* it would not make sense since all user are in the same directory.
Sam
Hello Sam,
Quoted 3 lines
For the dvb case, the .h files are used by files located in:
dvb/frontends
dvb/ttpci
Just to get things straight:
Current header files, which must be present for user space applications, are located in include/linux.
The internal header files for the dvb-core are indrivers/media/dvb/dvb-core.
These are accessed by drivers/media/dvb/frontends for example, this is true.
Quoted 1 line
Therefore I suggested linux/media.
There is no particular reason that they must stay there, so I suggest that I move them to include/dvb just like hch said.
Quoted 1 line
Sam
If this is ok, I'll do this with the next patchset.
CU
Michael.
Quoted 9 lines · Michael Hunold
Hello Sam,
Quoted 3 lines
For the dvb case, the .h files are used by files located in:
dvb/frontends
dvb/ttpciJust to get things straight:
Current header files, which must be present for user space applications, are located ininclude/linux.
You mean include/linux/dvb, I hope. Otherwise, it will break all user space applications.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 2 lines · Marcus Metzler
You mean
include/linux/dvb, I hope. Otherwise, it will break all user space applications.
No. At least I hope he didn't mean it :) Userspace has no _goddamn_ business to look at kernel headers. Just stick a copy of those into /usr/include/dvb/ for your applications that's in the dvb-dev or whatever package.
Quoted 8 lines · Christoph Hellwig
Quoted 2 lines · Marcus Metzler
You mean
include/linux/dvb, I hope. Otherwise, it will break all user space applications.No. At least I hope he didn't mean it :) Userspace has no _goddamn_ business to look at kernel headers. Just stick a copy of those into
/usr/include/dvb/for your applications that's in the dvb-dev or whatever package.
Strange, so why do you have include/linux/videodev.h and look at it with user space applications? Or what are you talking about? I am talking about../include/linux/dvb/video.h ../include/linux/dvb/version.h ../include/linux/dvb/osd.h../include/linux/dvb/net.h ../include/linux/dvb/frontend.h ../include/linux/dvb/dmx.h../include/linux/dvb/ca.h../include/linux/dvb/audio.h
Don't you like the extra directory?
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 2 lines · Marcus Metzler
Strange, so why do you have
include/linux/videodev.hand look at it with user space applications?
I don't look at it with userspace applications (ecept maybe less or cat..) and any application including it is broken.
Quoted 11 lines
I am talking about
../include/linux/dvb/video.h../include/linux/dvb/version.h../include/linux/dvb/osd.h../include/linux/dvb/net.h../include/linux/dvb/frontend.h../include/linux/dvb/dmx.h../include/linux/dvb/ca.h../include/linux/dvb/audio.hDon't you like the extra directory?
Quoted 7 lines · Christoph Hellwig
Quoted 2 lines · Marcus Metzler
Strange, so why do you have
include/linux/videodev.hand look at it with user space applications?I don't look at it with userspace applications (ecept maybe less or cat..) and any application including it is broken.
Hmm, you mean like xawtv and any other v4l application.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 1 line · Marcus Metzler
Hmm, you mean like xawtv and any other v4l application.
Yes.
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Marcus Metzler
Hmm, you mean like xawtv and any other v4l application.
Yes.
Well, then you are wrong. You need those headers for user space applications and also for the kernel. The define the communication structures. If you put them into /usr/include you always risk having different versions of those structures.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 4 lines · Marcus Metzler
Well, then you are wrong. You need those headers for user space applications and also for the kernel. The define the communication structures. If you put them into
/usr/includeyou always risk having different versions of those structures.
If the structures change incompatibly you're fucked anyway. Better have a copy in /usr/include that you can upgrade without updating libc also, that way you can at least get the new structures / defines in time.
Quoted 7 lines · Christoph Hellwig
Quoted 4 lines · Marcus Metzler
Well, then you are wrong. You need those headers for user space applications and also for the kernel. The define the communication structures. If you put them into
/usr/includeyou always risk having different versions of those structures.If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define AUDIO_SET_ATTRIBUTES _IOW('o', 17, audio_attributes_t)
#define AUDIO_SET_KARAOKE _IOW('o', 18, audio_karaoke_t)
to
#define AUDIO_SET_ATTRIBUTES _IOW('o', 47, audio_attributes_t)
#define AUDIO_SET_KARAOKE _IOW('o', 48, audio_karaoke_t)
or
typedef struct dvb_frontend_parameters {
uint32_t frequency; /* (absolute) frequency in Hz for QAM/OFDM */
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
} u;
} dvb_frontend_params_t;to
wtypedef struct dvb_frontend_parameters {
uint32_t frequency; /* (absolute) frequency in Hz for QAM/OFDM */
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_xyz_parameters xyz;
} u;
} dvb_frontend_params_t;won't change anything for user space apps. (We are only talking about self compiled ones here anyway, otherwise you won't need the headers.)
Quoted 3 lines
have a copy in
/usr/includethat you can upgrade without updating libc also, that way you can at least get the new structures / defines in time.
Anyway, even in user/include it should be under linux/dvb because that's just what it is Linux DVB. So the app has to include <linux/dvb/xxx.h>.
I don't care what distributions do. When I get a new kernel (no packages), I use the includes from that kernel and compile my apps with that. Distribution users won't compile anyway and if they do they probably need to get a kernel.org kernel.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 7 lines · Marcus Metzler
Quoted 1 line
If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 17, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 18, audio_karaoke_t)
Quoted 6 lines
to
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 47, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 48, audio_karaoke_t)or
In that case yes, you are screwed. Your ABI just changed incompatibly.
Quoted 3 lines
Anyway, even in user/include it should be under linux/dvb because that's just what it is Linux DVB. So the app has to include <
linux/dvb/xxx.h>.
No! <linux/*.h> is the namesapce for kernelheaders. Currently they're still in the the user includes, too (due to legacy reasons). The DVD API must move to a directory outside <linux/dvb>.
If you userland packages add headers to /usr/include/linux/ they are totally bogus.
Quoted 3 lines
I don't care what distributions do. When I get a new kernel (no packages), I use the includes from that kernel and compile my apps with that.
And that's wrong. You must always compile against the kernel headers that your libc was compiled against.
Quoted 8 lines · Christoph Hellwig
Quoted 7 lines · Marcus Metzler
Quoted 1 line
If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 17, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 18, audio_karaoke_t)
Quoted 8 lines
Quoted 6 lines
to
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 47, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 48, audio_karaoke_t)or
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
Quoted 9 lines
Quoted 4 lines
Anyway, even in user/include it should be under linux/dvb because that's just what it is Linux DVB. So the app has to include <
linux/dvb/xxx.h>.No! <linux/*.h> is the namesapce for kernelheaders. Currently they're still in the the user includes, too (due to legacy reasons). The DVD API must move to a directory outside <linux/dvb>.
Why (It's DVB by the way)? It's as close to the kernel as ls or cat and having two sets of the same includes is stupid.
Quoted 3 lines
If you userland packages add headers to
/usr/include/linux/they are totally bogus.
What packages? You are always talking about packages. There are no packages. There are only the kernel and my app. Nothing else. No copying of headers.
Quoted 7 lines
Quoted 3 lines
I don't care what distributions do. When I get a new kernel (no packages), I use the includes from that kernel and compile my apps with that.
And that's wrong. You must always compile against the kernel headers that your libc was compiled against.
There is no one who does that, not even distributions. The includes needed for libc are far less prone to change than v4l or dvb. And not as linux specific.
I see your point, but right now it's only academic and not practicable.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 11 lines · Marcus Metzler
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Marcus Metzler
Quoted 1 line
If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 17, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 18, audio_karaoke_t)to
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 47, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 48, audio_karaoke_t)or
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
Isn't the point of an application _binary_ interface, that you don't have to recompile?
Jörn
Signature · 2 lines
It does not matter how slowly you go, so long as you do not stop. -- Confucius
Quoted 15 lines · =?iso-8859-1?Q?J=F6rn?= Engel writes:
Quoted 14 lines · Marcus Metzler
Quoted 13 lines · Christoph Hellwig
Quoted 12 lines · Marcus Metzler
Quoted 1 line
If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 17, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 18, audio_karaoke_t)to
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 47, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 48, audio_karaoke_t)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
or
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
Isn't the point of an application _binary_ interface, that you don't have to recompile?
You don't need headers for binaries either, so what's your point.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 18 lines · Marcus Metzler
Quoted 17 lines · =?iso-8859-1?Q?J=F6rn?= Engel writes:
Quoted 16 lines · Marcus Metzler
Quoted 15 lines · Christoph Hellwig
Quoted 13 lines · Marcus Metzler
Quoted 1 line
If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 17, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 18, audio_karaoke_t)to
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 47, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 48, audio_karaoke_t)or
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
Isn't the point of an application _binary_ interface, that you don't have to recompile?
You don't need headers for binaries either, so what's your point.
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.
Jörn
Signature · 3 lines
Beware of bugs in the above code; I have only proved it correct, but not tried it. -- Donald Knuth
Quoted 26 lines · =?iso-8859-1?Q?J=F6rn?= Engel writes:
Quoted 25 lines · Marcus Metzler
Quoted 23 lines · =?iso-8859-1?Q?J=F6rn?= Engel writes:
Quoted 11 lines · Marcus Metzler
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Marcus Metzler
Quoted 1 line
If the structures change incompatibly you're fucked anyway. Better
Not necessarily, e.g. changing
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 17, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 18, audio_karaoke_t)to
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
#define
AUDIO_SET_ATTRIBUTES_IOW('o', 47, audio_attributes_t)
#defineAUDIO_SET_KARAOKE_IOW('o', 48, audio_karaoke_t)or
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
Isn't the point of an application _binary_ interface, that you don't have to recompile?
Quoted 6 lines
Quoted 1 line
You don't need headers for binaries either, so what's your point.
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.
That was kind of the point. If I have to check and copy the includes all the time I may run into trouble because of such changes. Whereas without that, I only have to recompile. I don't have to check each and evry possible place where old headers may be, which may even be different for every distribution.
Quoted 3 lines
Worse if there is a new semantic for 17 or 18, in that case the old binaries may break randomly, depending on kernel version.
I was never talking about binaries. Of course, binaries break and you won't make such radical changes in your drivers. This was only an example.
The problem with this entire thread was that Christoph was trying to make a point, and I was only trying to make sure that I don't get emails complaining about how my sources won't compile with the kernel drivers (not that I would ever use those).
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 5 lines · Marcus Metzler
That was kind of the point. If I have to check and copy the includes all the time I may run into trouble because of such changes. Whereas without that, I only have to recompile. I don't have to check each and evry possible place where old headers may be, which may even be different for every distribution.
If that's your attitude we should drop dvb from the kernel again. The Linux Kernel has a stable userspace ABI.
Quoted 6 lines · Christoph Hellwig
Quoted 3 lines
Quoted 1 line
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
If you need to recompile your ABI changed. And yes, then your absolutely screwed.
You may be, I am not.
Quoted 5 lines
Quoted 3 lines
Why (It's DVB by the way)? It's as close to the kernel as ls or cat and having two sets of the same includes is stupid.
No, it's not. One if for the driver you compile and one for the application.
Yeah, yeah. I know, get off it. They are the same.
Quoted 5 lines
Quoted 2 lines
What packages? You are always talking about packages. There are no packages. There are only the kernel and my app. Nothing else. No copying of headers.
Then you need to add a package with the userland header (which, as I already said might be exactly the same ones as those in the kernel tree).
What are those packages you are talking about? I am not making a distribution.
Quoted 6 lines
Quoted 3 lines
There is no one who does that, not even distributions. The includes needed for libc are far less prone to change than v4l or dvb. And not as linux specific.
Oh yes, everyone does. Ever looked at an errata kernel from RH, SuSE or Debian? Yes, they never change what's
/usr/include/.
So where are all the libc packages for each and every kernel package in debian?
Quoted 3 lines
Quoted 1 line
I see your point, but right now it's only academic and not practicable.
It's how Linux works. If you don't like that play with SCO Unix or MacOS.
No, it's how a linux distribution may work ( or should I say a GNU/Linux distribution).
Quoted 10 lines · Marcus Metzler
Quoted 5 lines
That was kind of the point. If I have to check and copy the includes all the time I may run into trouble because of such changes. Whereas without that, I only have to recompile. I don't have to check each and evry possible place where old headers may be, which may even be different for every distribution.
If that's your attitude we should drop dvb from the kernel again. The Linux Kernel has a stable userspace ABI.
Yes, that's why it's called the unstable branch. You are talking about a ready all done distribution. I am not. I am talking about developement. I don't know what your problem is. If you want the app in your distribution then change it to the way you want.
Fact is that you need the headers in the kernel, in order to compile the drivers.
Fact is that I need those same headers for my applications, not some others somewhere else.
Fact is that this is the kernel list and we are talking about a developement kernel.
All you are talking about is some user who gets a distribution and wants to compile his own programs. But they don't use DEVELOPEMENT kernels. And the don't write low level apps to test the drivers.
Get over it, I am done feeding the trolls.
Marcus
Signature · 5 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
Quoted 9 lines · Marcus Metzler
Quoted 6 lines · Christoph Hellwig
Quoted 3 lines
Quoted 1 line
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
If you need to recompile your ABI changed. And yes, then your absolutely screwed.
You may be, I am not.
If you run a kernel with a different ABI than the one described in /usr/src/linux/include (or whereever you happen to put your symlink to), you are. The fact that you have a kernel source tree which describes a kernel version in /usr/src/linux, doesn't necessarly mean, that it describes the _currently running_ kernel.
If you upgrade and your ABI breaks, you're toast. If you recompile and the headers you include do not describe the same ABI as the kernel you're running, you're still toast. If you symlink your user space include directory to a kernel source tree directory, then you're still toast. It doesn't matter.
You need an ABI that matches your applications for running existing binaries.
You need headers for user space and kernel space that describe the same thing to compile applications matching to that kernel.
You need headers that describe the ABI of the running kernel to compile an application that runs on your current kernel.
Your idea of linking kernel headers to user space can break. Christophs' (and the widely accepted) policy of having separate headers for kernel and user space can break as well. None of these policies is a guarantee for having matching headers to your running kernel.
The only guarantee would be having an "includes-fs" which synthesizes include headers in a sysfs/procfs way that describe the currently running kernel.... (ducks, runs)
Regards
Henning
Quoted 81 lines
Quoted 5 lines
Quoted 3 lines
Why (It's DVB by the way)? It's as close to the kernel as ls or cat and having two sets of the same includes is stupid.
No, it's not. One if for the driver you compile and one for the application.
Yeah, yeah. I know, get off it. They are the same.
Quoted 5 lines
Quoted 2 lines
What packages? You are always talking about packages. There are no packages. There are only the kernel and my app. Nothing else. No copying of headers.
Then you need to add a package with the userland header (which, as I already said might be exactly the same ones as those in the kernel tree).
What are those packages you are talking about? I am not making a distribution.
Quoted 6 lines
Quoted 3 lines
There is no one who does that, not even distributions. The includes needed for libc are far less prone to change than v4l or dvb. And not as linux specific.
Oh yes, everyone does. Ever looked at an errata kernel from RH, SuSE or Debian? Yes, they never change what's
/usr/include/.So where are all the libc packages for each and every kernel package in debian?
Quoted 3 lines
Quoted 1 line
I see your point, but right now it's only academic and not practicable.
It's how Linux works. If you don't like that play with SCO Unix or MacOS.
No, it's how a linux distribution may work ( or should I say a GNU/Linux distribution).
Quoted 10 lines · Marcus Metzler
Quoted 5 lines
That was kind of the point. If I have to check and copy the includes all the time I may run into trouble because of such changes. Whereas without that, I only have to recompile. I don't have to check each and evry possible place where old headers may be, which may even be different for every distribution.
If that's your attitude we should drop dvb from the kernel again. The Linux Kernel has a stable userspace ABI.
Yes, that's why it's called the unstable branch. You are talking about a ready all done distribution. I am not. I am talking about developement. I don't know what your problem is. If you want the app in your distribution then change it to the way you want.
Fact is that you need the headers in the kernel, in order to compile the drivers.
Fact is that I need those same headers for my applications, not some others somewhere else.
Fact is that this is the kernel list and we are talking about a developement kernel.
All you are talking about is some user who gets a distribution and wants to compile his own programs. But they don't use DEVELOPEMENT kernels. And the don't write low level apps to test the drivers.
Get over it, I am done feeding the trolls.
Marcus
Signature · 13 lines
/--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | [email protected] | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 8 lines
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [email protected] +49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --- Quote of the week: "It is pointless to tell people anything when you know that they won't process the message." --- Jonathan Revusky
Quoted 7 lines · Jörn Engel
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))
Hello Alan and others,
Quoted 9 lines
Quoted 7 lines
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.
Quoted 7 lines
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.
Quoted 6 lines · Michael Hunold
In
include/linux/dvbwe 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/dvbCurrently, you must copy them by hand or create a symlink, because there hasn't been an official kernel with the dvb driver subsystem yet.
And that's the whole point. In fact I hear exactly that problem from a friend at SuSE who maintained an (inofficial?) dvb package. He packaged the kernel driver but of course it's not part of the official SuSE kernel and even more so the kernel headers package that is created with the kernel package but doesn't change during the lifetime of the glibc package. Now he's not allowed to just write into /usr/include/linux/ either because that directory is owned by the kernel headers package.
Please just get over it and put a copy of the headers into /usr/include/dvb, this makes life easier for everyone.
Quoted 4 lines · Christoph Hellwig
Quoted 3 lines · Michael Hunold
In
include/linux/dvbwe 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.
Actually the last (backwards compatible) change to the v3 API was just about two months ago. The last really incompatible change was more than a year ago, if you don't count the change to the previously unused/unusable VIDEO_GET_EVENT ioctl three months ago.
Meanwhile we have begun working on a "v4" DVB API, which will have many incompatible changes. This changes are necessary to support advanced features of newer set-top-box chips sets which are not yet used in DVB PCI-cards or USB-boxes. I doubt there will be a publicly available driver with this API this year, as there isn't any code yet, just some conceptual work. Anyway, v3 will be stable because v4 exists.
Quoted 13 lines
Quoted 4 lines
In an ideal world, these header files would
be included in your glibc distribution at/usr/include/linux/dvbCurrently, you must copy them by hand or create a symlink, because there hasn't been an official kernel with the dvb driver subsystem yet.And that's the whole point. In fact I hear exactly that problem from a friend at SuSE who maintained an (inofficial?) dvb package. He packaged the kernel driver but of course it's not part of the official SuSE kernel and even more so the kernel headers package that is created with the kernel package but doesn't change during the lifetime of the glibc package. Now he's not allowed to just write into
/usr/include/linux/either because that directory is owned by the kernel headers package.
Quoted 2 lines
Please just get over it and put a copy of the headers into
/usr/include/dvb, this makes life easier for everyone.
Three things:
1. glibc has nothing to do with driver ioctls (exceptions exist for "standard" drivers, e.g. tty handling); important for glibc is that the system call interface does not change, so the files in /usr/include/linux and /usr/include/asm must match glibc. OTOH ioctl definitions for drivers must match the driver that is currently in use. If the ioctl definitions change, binary compatiblity is broken (bad), but source compatiblity can be maintained if the driver API header files are updated. If they are not updated, source compatiblity is also broken (really bad).
2. It seems to me that /usr/include/linux is the place where almost all drivers put their ioctl API definitions (input.h, rtc.h, nvram.h, matroxfb.h, etc.). So it seemed the right place for the DVB API is /usr/include/linux/dvb/. I thought this is the Linux way.
3. Consequently applications use e.g. #include <linux/dvb/frontend.h>, and to maintain application source compatibility this include path must not be changed. Distributions could put the API headers in /usr/include/dvb/linux/dvb/ and compile applications with -I/usr/include/dvb.
I think it is a fundamental problem that driver ioctl definitions (relatively frequent changes for many drivers) are mixed with low level kernel ABI definitions (few changes). Maybe it would be better to separate all driver APIs in linux/include/drivers/ and symlink that to /usr/include/drivers/, while /usr/include/{linux,asm} can match glibc.
Johannes
Quoted 3 lines · Marcus Metzler
Quoted 1 line
In that case yes, you are screwed. Your ABI just changed incompatibly.
Not if you recompile.
If you need to recompile your ABI changed. And yes, then your absolutely screwed.
Quoted 7 lines
Quoted 4 lines
No! <linux/*.h> is the namesapce for kernelheaders. Currently they're still in the the user includes, too (due to legacy reasons). The DVD API must move to a directory outside <linux/dvb>.
Why (It's DVB by the way)? It's as close to the kernel as ls or cat and having two sets of the same includes is stupid.
No, it's not. One if for the driver you compile and one for the application.
Quoted 7 lines
Quoted 3 lines
If you userland packages add headers to
/usr/include/linux/they are totally bogus.What packages? You are always talking about packages. There are no packages. There are only the kernel and my app. Nothing else. No copying of headers.
Then you need to add a package with the userland header (which, as I already said might be exactly the same ones as those in the kernel tree).
Quoted 7 lines
Quoted 3 lines
And that's wrong. You must always compile against the kernel headers that your libc was compiled against.
There is no one who does that, not even distributions. The includes needed for libc are far less prone to change than v4l or dvb. And not as linux specific.
Oh yes, everyone does. Ever looked at an errata kernel from RH, SuSE or Debian? Yes, they never change what's /usr/include/.
Quoted 1 line
I see your point, but right now it's only academic and not practicable.
It's how Linux works. If you don't like that play with SCO Unix or MacOS.
Quoted 8 lines · Christoph Hellwig
Quoted 2 lines · Marcus Metzler
You mean
include/linux/dvb, I hope. Otherwise, it will break all user space applications.No. At least I hope he didn't mean it :) Userspace has no _goddamn_ business to look at kernel headers. Just stick a copy of those into
/usr/include/dvb/for your applications that's in the dvb-dev or whatever package.
Christoph, while I agree with you, I also see why a lot of people just symlink /usr/include/linux to /usr/src/.../include/linux. Pure convenience and the lack of a dedicated collection of userspace headers outside a distributions scope.
Seperating userspace headers from kernel headers would also be a good thing, as the #ifdef __KERNEL__ #else #endif orgy could finally be reduced a bit.
Since these headers do depend on the kernel version and should be the official interface between kernel and userspace, maintaining them inside the kernel tree would also, imho, be a Good Thing.
So imnsho the "don't use the kernel headers" comment I read on a common basis is not a very helpful advice, as long as we are missing in this respect.
Or did I miss something important and just exposed my stupidity?
Jörn
Signature · 4 lines
Public Domain - Free as in Beer General Public - Free as in Speech BSD License - Free as in Enterprise Shared Source - Free as in "Work will make you..."
Quoted 4 lines · Jörn Engel
Christoph, while I agree with you, I also see why a lot of people just symlink
/usr/include/linuxto/usr/src/.../include/linux. Pure convenience and the lack of a dedicated collection of userspace headers outside a distributions scope.
Well, that symlinking is okay as long as you never ever touch /usr/src/linux again.
Quoted 1 line
Or did I miss something important and just exposed my stupidity?
No one said they can't be the same header and actually maintaining them in the kernel tree is fine to. Just put them in a different location for userspace so you can update them independant of the kernel. Look at e.g. XFS - most headers in /usr/include/xfs/ are just copied from fs/xfs/ in the kernel tree. But they're always the ones matching the libxfs you installed no matter what XFS version your currently running kernel has (or no XFS at all).
And that's the fundamental issue here, the userland header must be independant from the actually running kernel or some random source tree that's somewhere on your disk. Copying the content to /usr/include/linux does work but it's really suboptimal. You don't want to upgrade your libc just because you want to be able to use the new features in the dvb driver you just installed. A separate dvb-dev packages that has a copy of those headers in /usr/include/dvb is the much better choice.