DVB Include files

DVB Include files

[Sam Ravnborg]

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

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 05:06:29PM +0200, Sam Ravnborg wrote:
> 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>/

Re: DVB Include files

[Sam Ravnborg]

On Wed, Jun 25, 2003 at 04:08:30PM +0100, Christoph Hellwig wrote:
> On Wed, Jun 25, 2003 at 05:06:29PM +0200, Sam Ravnborg wrote:
> > 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

Re: DVB Include files

[Michael Hunold]

Hello Sam,

> 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 in
drivers/media/dvb/dvb-core.

These are accessed by drivers/media/dvb/frontends for example,
this is true.

 > 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.

> 	Sam

If this is ok, I'll do this with the next patchset.

CU
Michael.

Re: DVB Include files

[Marcus Metzler]

Michael Hunold writes:
 > Hello Sam,
 > 
 > > 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.

You mean include/linux/dvb, I hope. Otherwise, it will break all user space
applications.

Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 06:49:50PM +0200, Marcus Metzler wrote:
> 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.

Re: DVB Include files

[Marcus Metzler]

Christoph Hellwig writes:
 > On Wed, Jun 25, 2003 at 06:49:50PM +0200, Marcus Metzler wrote:
 > > 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 07:13:42PM +0200, Marcus Metzler wrote:
> Strange, so why do you have include/linux/videodev.h and 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.

> 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?

Re: DVB Include files

[Marcus Metzler]

Christoph Hellwig writes:
 > On Wed, Jun 25, 2003 at 07:13:42PM +0200, Marcus Metzler wrote:
 > > Strange, so why do you have include/linux/videodev.h and 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 07:22:09PM +0200, Marcus Metzler wrote:
> Hmm, you mean like xawtv and any other v4l application.

Yes.

Re: DVB Include files

[Jörn Engel]

On Wed, 25 June 2003 17:55:13 +0100, Christoph Hellwig wrote:
> On Wed, Jun 25, 2003 at 06:49:50PM +0200, Marcus Metzler wrote:
> > 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

-- 
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..."

Re: DVB Include files

[Marcus Metzler]

Christoph Hellwig writes:
 > On Wed, Jun 25, 2003 at 07:22:09PM +0200, Marcus Metzler wrote:
 > > 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 07:27:03PM +0200, Jörn Engel wrote:
> 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.

Well, that symlinking is okay as long as you never ever touch /usr/src/linux
again.

> 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.

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 07:30:38PM +0200, Marcus Metzler wrote:
> 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. 

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.

Re: DVB Include files

[Marcus Metzler]

Christoph Hellwig writes:
 > On Wed, Jun 25, 2003 at 07:30:38PM +0200, Marcus Metzler wrote:
 > > 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. 
 > 
 > 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.) 

 > 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.
 > 
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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 08:09:51PM +0200, Marcus Metzler wrote:
>  > 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

In that case yes, you are screwed.  Your ABI just changed incompatibly.

> 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.

> 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.

Re: DVB Include files

[Marcus Metzler]

Christoph Hellwig writes:
 > On Wed, Jun 25, 2003 at 08:09:51PM +0200, Marcus Metzler wrote:
 > >  > 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
 > 
 > In that case yes, you are screwed.  Your ABI just changed incompatibly.

Not if you recompile.

 > 
 > > 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. 

 > 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.

 > > 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Jörn Engel]

On Wed, 25 June 2003 20:43:23 +0200, Marcus Metzler wrote:
> Christoph Hellwig writes:
>  > On Wed, Jun 25, 2003 at 08:09:51PM +0200, Marcus Metzler wrote:
>  > >  > 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
>  > 
>  > 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

-- 
It does not matter how slowly you go, so long as you do not stop.
-- Confucius

Re: DVB Include files

[Marcus Metzler]

=?iso-8859-1?Q?J=F6rn?= Engel writes:
 > On Wed, 25 June 2003 20:43:23 +0200, Marcus Metzler wrote:
 > > Christoph Hellwig writes:
 > >  > On Wed, Jun 25, 2003 at 08:09:51PM +0200, Marcus Metzler wrote:
 > >  > >  > 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
 > >  > 
 > >  > 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Jörn Engel]

On Wed, 25 June 2003 22:09:31 +0200, Marcus Metzler wrote:
> =?iso-8859-1?Q?J=F6rn?= Engel writes:
>  > On Wed, 25 June 2003 20:43:23 +0200, Marcus Metzler wrote:
>  > > Christoph Hellwig writes:
>  > >  > On Wed, Jun 25, 2003 at 08:09:51PM +0200, Marcus Metzler wrote:
>  > >  > >  > 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
>  > >  > 
>  > >  > 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

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth

Re: DVB Include files

[Marcus Metzler]

=?iso-8859-1?Q?J=F6rn?= Engel writes:
 > On Wed, 25 June 2003 22:09:31 +0200, Marcus Metzler wrote:
 > > =?iso-8859-1?Q?J=F6rn?= Engel writes:
 > >  > On Wed, 25 June 2003 20:43:23 +0200, Marcus Metzler wrote:
 > >  > > Christoph Hellwig writes:
 > >  > >  > On Wed, Jun 25, 2003 at 08:09:51PM +0200, Marcus Metzler wrote:
 > >  > >  > >  > 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
 > >  > >  > 
 > >  > >  > 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.

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.

 > 
 > 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 08:43:23PM +0200, Marcus Metzler wrote:
>  > 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.

>  > 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.

>  > 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).

>  > 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/.

> 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.

Re: DVB Include files

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 10:48:36PM +0200, Marcus Metzler wrote:
> 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.

Re: DVB Include files

[Marcus Metzler]

Christoph Hellwig writes:
 > >  > 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.

 > > 
 > > 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.

 > > 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.

 > > 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?

 > > 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).

> On Wed, Jun 25, 2003 at 10:48:36PM +0200, Marcus Metzler wrote:
 > > 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

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
|--------------------------------|-----------------------------------|
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/

Re: DVB Include files

[Alan Cox]

On Mer, 2003-06-25 at 21:23, Jörn Engel wrote:
> 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))

Re: DVB Include files

[Michael Hunold]

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.

Re: DVB Include files

[Christoph Hellwig]

On Thu, Jun 26, 2003 at 10:18:49AM +0200, Michael Hunold wrote:
> 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.

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.

Re: DVB Include files

[Johannes Stezenbach]

On Thu, Jun 26, 2003 at 09:24:44AM +0100, Christoph Hellwig wrote:
> On Thu, Jun 26, 2003 at 10:18:49AM +0200, Michael Hunold wrote:
> > 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.

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.

> > 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.
> 
> 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.

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

Re: DVB Include files

[Henning P. Schmiedehausen]

Marcus Metzler <mocm@metzlerbros.de> writes:

>Christoph Hellwig writes:
> > >  > 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



> > > 
> > > 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.

> > > 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.

> > > 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?

> > > 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).

>> On Wed, Jun 25, 2003 at 10:48:36PM +0200, Marcus Metzler wrote:
> > > 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

>-- 
>/--------------------------------------------------------------------\
>| Dr. Marcus O.C. Metzler        |                                   |
>|--------------------------------|-----------------------------------|
>| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
>\--------------------------------------------------------------------/



>-
>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/

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +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