Driver headers used by alsa-lib

Driver headers used by alsa-lib

[Pavel Roskin]

Hello!

There is another configuration problem that needs to be fixed.  I had ALSA
already installed (CVS version as of a week ago or so).  Today I compiled
alsa-driver, alsa-lib and alsa-util and then started installing them.

I found that "make install" caused recompilation in alsa-lib.  It used to
be like that, but this time I wanted to do it right.

I found that the reason for recompilation is new files in
/usr/include/sound/, in particular asoundef.h.  It turmed out that there
are two different files with this name - one is
alsa-lib/include/asoundef.h, the other is alsa-kernel/include/asoundef.h.

Object files under alsa-lib were compiled against headers in
/usr/include/sound/, and "make install" in alsa-kernel installed new
headers there.  The dependency was recorded by the compiler, so the
alsa-lib object files became out of date.

It seems to me that there are at least two things wrong here.  First is
that the kernel should not be installing its headers in places where they
can be accidentally used.  Most software should not need those headers at
all.

For example, Linux kernel includes are available under linux and asm in
/usr/include.  When I'm using them, I'm well aware of the fact that it's
essentially a private kernel interface and that I should avoid it if
possible.

If I include <sound/asoundef.h>, I would assume that it's something for 
user-space software, not for kernel drivers.  Maybe kernel headers should 
be installed under /usr/include/sound/kernel if we install them at all?

The other problem is that alsa-lib should be using its own headers from
its own distribution rather than the preinstalled ones, otherwise we have 
a whole new problem with compiling against an older library.

I'm ready to provide patches once somebody confirms that my understanding 
of the problem is correct.

-- 
Regards,
Pavel Roskin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Driver headers used by alsa-lib

[Peter L Jones]

On Friday 04 Oct 2002 18:20, Pavel Roskin wrote:
> Hello!
>
[snip - forgive me chopping the lot :-)]
>
> I'm ready to provide patches once somebody confirms that my understanding
> of the problem is correct.

I think you're perfectly correct.

It sounds like ALSA is doing _exactly_ like what the kernel developers used to 
complain about the glibc developers doing - compiling against the kernel 
headers.  As you suggest, it's _wrong_!

There needs to be a clear split - kernel space code and user space code.  
Consider them maintained in separate universes.  Only at runtime do they 
_need_ to co-exist.  If the kernel developers change an interface, they need 
to tell the user-space (library) developers what the change is.

The two developer teams could have entirely different requirements for 
organising header files, too...

(Well, it beats "me too" but, having reread the above, I'd like to add that I 
think I've gone a little overboard :-).)

-- Peter



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Driver headers used by alsa-lib

[Takashi Iwai]

At Fri, 4 Oct 2002 13:20:32 -0400 (EDT),
Pavel Roskin wrote:
> 
> Hello!
> 
> There is another configuration problem that needs to be fixed.  I had ALSA
> already installed (CVS version as of a week ago or so).  Today I compiled
> alsa-driver, alsa-lib and alsa-util and then started installing them.
> 
> I found that "make install" caused recompilation in alsa-lib.  It used to
> be like that, but this time I wanted to do it right.
> 
> I found that the reason for recompilation is new files in
> /usr/include/sound/, in particular asoundef.h.  It turmed out that there
> are two different files with this name - one is
> alsa-lib/include/asoundef.h, the other is alsa-kernel/include/asoundef.h.
> 
> Object files under alsa-lib were compiled against headers in
> /usr/include/sound/, and "make install" in alsa-kernel installed new
> headers there.  The dependency was recorded by the compiler, so the
> alsa-lib object files became out of date.
> 
> It seems to me that there are at least two things wrong here.  First is
> that the kernel should not be installing its headers in places where they
> can be accidentally used.  Most software should not need those headers at
> all.
> 
> For example, Linux kernel includes are available under linux and asm in
> /usr/include.  When I'm using them, I'm well aware of the fact that it's
> essentially a private kernel interface and that I should avoid it if
> possible.

well, not all people are aware of that inclusion of kernel headers
will break portability ;)

> If I include <sound/asoundef.h>, I would assume that it's something for 
> user-space software, not for kernel drivers.  Maybe kernel headers should 
> be installed under /usr/include/sound/kernel if we install them at all?
 
sound header files are not necessary except for alsa-lib and hardware
specific applications like alsa-tools' ones.
i think /usr/include/sound is confusing.  it looks like normal header
files...


> The other problem is that alsa-lib should be using its own headers from
> its own distribution rather than the preinstalled ones, otherwise we have 
> a whole new problem with compiling against an older library.

right.

actually i use the extracted alsa-kernel header files to build
alsa-lib rpm package, too, so why not in the alsa-lib tree itself?

we need only three files from alsa-kernel, namely, asound.h,
asoundef.h and asequencer.h.  they can be copied into alsa-lib tree,
for example, under alsa-lib/include/alsa-kernel directory, which will
be not copied to the public place.

or, we can keep the alsa-kernel header files on
/usr/include/alsa/kernel directory, so that we don't need two distinct
directories which may confuse people.  (even in this case, the three
files above should be duplicated in alsa-lib, though.)


Jaroslav, how about this?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Driver headers used by alsa-lib

[Jaroslav Kysela]

On Tue, 8 Oct 2002, Takashi Iwai wrote:

> At Fri, 4 Oct 2002 13:20:32 -0400 (EDT),
> Pavel Roskin wrote:
> > 
> > Hello!
> > 
> > There is another configuration problem that needs to be fixed.  I had ALSA
> > already installed (CVS version as of a week ago or so).  Today I compiled
> > alsa-driver, alsa-lib and alsa-util and then started installing them.
> > 
> > I found that "make install" caused recompilation in alsa-lib.  It used to
> > be like that, but this time I wanted to do it right.
> > 
> > I found that the reason for recompilation is new files in
> > /usr/include/sound/, in particular asoundef.h.  It turmed out that there
> > are two different files with this name - one is
> > alsa-lib/include/asoundef.h, the other is alsa-kernel/include/asoundef.h.
> > 
> > Object files under alsa-lib were compiled against headers in
> > /usr/include/sound/, and "make install" in alsa-kernel installed new
> > headers there.  The dependency was recorded by the compiler, so the
> > alsa-lib object files became out of date.
> > 
> > It seems to me that there are at least two things wrong here.  First is
> > that the kernel should not be installing its headers in places where they
> > can be accidentally used.  Most software should not need those headers at
> > all.
> > 
> > For example, Linux kernel includes are available under linux and asm in
> > /usr/include.  When I'm using them, I'm well aware of the fact that it's
> > essentially a private kernel interface and that I should avoid it if
> > possible.
> 
> well, not all people are aware of that inclusion of kernel headers
> will break portability ;)
> 
> > If I include <sound/asoundef.h>, I would assume that it's something for 
> > user-space software, not for kernel drivers.  Maybe kernel headers should 
> > be installed under /usr/include/sound/kernel if we install them at all?
>  
> sound header files are not necessary except for alsa-lib and hardware
> specific applications like alsa-tools' ones.
> i think /usr/include/sound is confusing.  it looks like normal header
> files...
> 
> 
> > The other problem is that alsa-lib should be using its own headers from
> > its own distribution rather than the preinstalled ones, otherwise we have 
> > a whole new problem with compiling against an older library.
> 
> right.
> 
> actually i use the extracted alsa-kernel header files to build
> alsa-lib rpm package, too, so why not in the alsa-lib tree itself?
> 
> we need only three files from alsa-kernel, namely, asound.h,
> asoundef.h and asequencer.h.  they can be copied into alsa-lib tree,
> for example, under alsa-lib/include/alsa-kernel directory, which will
> be not copied to the public place.
> 
> or, we can keep the alsa-kernel header files on
> /usr/include/alsa/kernel directory, so that we don't need two distinct
> directories which may confuse people.  (even in this case, the three
> files above should be duplicated in alsa-lib, though.)
> 
> 
> Jaroslav, how about this?

The duplication of headers does not sound so bad.
The /usr/include/alsa/kernel is a good place.
Do not forget to include all headers files (or portions) which can be 
used from user space (emu10k1.h, sscape_ioctl.h, sb16_csp.h, asound_fm.h, 
probably all ainstr_* files etc.).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Driver headers used by alsa-lib

[Takashi Iwai]

At Wed, 9 Oct 2002 08:58:12 +0200 (CEST),
Jaroslav wrote:
> 
> > we need only three files from alsa-kernel, namely, asound.h,
> > asoundef.h and asequencer.h.  they can be copied into alsa-lib tree,
> > for example, under alsa-lib/include/alsa-kernel directory, which will
> > be not copied to the public place.
> > 
> > or, we can keep the alsa-kernel header files on
> > /usr/include/alsa/kernel directory, so that we don't need two distinct
> > directories which may confuse people.  (even in this case, the three
> > files above should be duplicated in alsa-lib, though.)
> > 
> > 
> > Jaroslav, how about this?
> 
> The duplication of headers does not sound so bad.
> The /usr/include/alsa/kernel is a good place.
> Do not forget to include all headers files (or portions) which can be 
> used from user space (emu10k1.h, sscape_ioctl.h, sb16_csp.h, asound_fm.h, 
> probably all ainstr_* files etc.).

as mentioned above, alsa-lib needs only the three header files from
alsa-kernel.  hence the duplication is necessary only for them, and
it's not too much.

the installation of kernel header files shall be done anyway from
alsa-driver, so the all files will be there.  should be no problem.

ok, i'll try this.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Driver headers used by alsa-lib

[Takashi Iwai]

sorry, corrections:

At Wed, 09 Oct 2002 11:55:44 +0200,
I wrote:
> 
> as mentioned above, alsa-lib needs only the three header files from
> alsa-kernel.  hence the duplication is necessary only for them, and
> it's not too much.
 
also ainstr_*.h are necessary, too.

> the installation of kernel header files shall be done anyway from
> alsa-driver, so the all files will be there.  should be no problem.

it turned out that the files are included as <sound/*.h>, so
apparently we need to put the files under sound directory.

the candidate is,

1. /usr/include/alsa/kernel/sound/*.h
2. /usr/include/alsa/sound/*.h
3. /usr/include/sound/*.h	(as it is)

i'd prefer 1 since it's clear that the header files belong to the
kernel, but it's a bit too deep.

suggestions?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf