[PATCH 24/45] hdspm.h: include stdint.h in userspace

[PATCH 24/45] hdspm.h: include stdint.h in userspace

[Mikko Rapeli]

Fixes compilation error:

sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/sound/hdspm.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/sound/hdspm.h b/include/uapi/sound/hdspm.h
index d956c35..f799828 100644
--- a/include/uapi/sound/hdspm.h
+++ b/include/uapi/sound/hdspm.h
@@ -20,6 +20,12 @@
  *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#ifdef __KERNEL__
+#include <linux/types.h>
+#else
+#include <stdint.h>
+#endif
+
 /* Maximum channels is 64 even on 56Mode you have 64playbacks to matrix */
 #define HDSPM_MAX_CHANNELS      64
 
-- 
2.1.4

Re: [PATCH 24/45] hdspm.h: include stdint.h in userspace

[Takashi Iwai]

At Tue, 17 Feb 2015 00:05:27 +0100,
Mikko Rapeli wrote:
> 
> Fixes compilation error:
> 
> sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/hdspm.h | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/uapi/sound/hdspm.h b/include/uapi/sound/hdspm.h
> index d956c35..f799828 100644
> --- a/include/uapi/sound/hdspm.h
> +++ b/include/uapi/sound/hdspm.h
> @@ -20,6 +20,12 @@
>   *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>   */
>  
> +#ifdef __KERNEL__
> +#include <linux/types.h>
> +#else
> +#include <stdint.h>
> +#endif
> +
>  /* Maximum channels is 64 even on 56Mode you have 64playbacks to matrix */
>  #define HDSPM_MAX_CHANNELS      64
>  
> -- 
> 2.1.4
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 24/45] hdspm.h: include stdint.h in userspace

[Mikko Rapeli]

On Tue, Feb 17, 2015 at 07:46:02AM +0100, Takashi Iwai wrote:
> At Tue, 17 Feb 2015 00:05:27 +0100,
> Mikko Rapeli wrote:
> > 
> > Fixes compilation error:
> > 
> > sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> 
> Applied for 3.21, thanks.

Sorry, but this should maybe be dropped or reverted from the sound tree.

Arnd and others pointed out that kernel headers should be using __u32 etc
types from linux/types.h instead of including stdint.h from libc and using
uint32_t et al.

I'll post a new patch version for hdspm.h too in the next revision.

-Mikko

> 
> Takashi
> 
> > ---
> >  include/uapi/sound/hdspm.h | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/include/uapi/sound/hdspm.h b/include/uapi/sound/hdspm.h
> > index d956c35..f799828 100644
> > --- a/include/uapi/sound/hdspm.h
> > +++ b/include/uapi/sound/hdspm.h
> > @@ -20,6 +20,12 @@
> >   *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> >   */
> >  
> > +#ifdef __KERNEL__
> > +#include <linux/types.h>
> > +#else
> > +#include <stdint.h>
> > +#endif
> > +
> >  /* Maximum channels is 64 even on 56Mode you have 64playbacks to matrix */
> >  #define HDSPM_MAX_CHANNELS      64
> >  
> > -- 
> > 2.1.4
> > 

Re: [PATCH 24/45] hdspm.h: include stdint.h in userspace

[Takashi Iwai]

At Wed, 11 Mar 2015 02:28:12 +0200,
Mikko Rapeli wrote:
> 
> On Tue, Feb 17, 2015 at 07:46:02AM +0100, Takashi Iwai wrote:
> > At Tue, 17 Feb 2015 00:05:27 +0100,
> > Mikko Rapeli wrote:
> > > 
> > > Fixes compilation error:
> > > 
> > > sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’
> > > 
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> > 
> > Applied for 3.21, thanks.
> 
> Sorry, but this should maybe be dropped or reverted from the sound tree.
> 
> Arnd and others pointed out that kernel headers should be using __u32 etc
> types from linux/types.h instead of including stdint.h from libc and using
> uint32_t et al.
> 
> I'll post a new patch version for hdspm.h too in the next revision.

Then please post an incremental patch to for-next branch of sound git
tree (or the current linux-next tree).


Takashi

[PATCH 35/45] include/uapi/sound/asound.h: include stdlib.h in userspace

[Mikko Rapeli]

Fixes compiler errors like:
error: field ‘trigger_tstamp’ has incomplete type
error: invalid application of ‘sizeof’ to incomplete t
ype ‘struct timespec’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/sound/asound.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index 941d32f..af156b0 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -25,6 +25,9 @@
 
 #include <linux/types.h>
 
+#ifndef __KERNEL__
+#include <stdlib.h>
+#endif
 
 /*
  *  protocol version
-- 
2.1.4

Re: [PATCH 35/45] include/uapi/sound/asound.h: include stdlib.h in userspace

[Takashi Iwai]

At Tue, 17 Feb 2015 00:05:38 +0100,
Mikko Rapeli wrote:
> 
> Fixes compiler errors like:
> error: field ‘trigger_tstamp’ has incomplete type
> error: invalid application of ‘sizeof’ to incomplete t
> ype ‘struct timespec’
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/asound.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
> index 941d32f..af156b0 100644
> --- a/include/uapi/sound/asound.h
> +++ b/include/uapi/sound/asound.h
> @@ -25,6 +25,9 @@
>  
>  #include <linux/types.h>
>  
> +#ifndef __KERNEL__
> +#include <stdlib.h>
> +#endif
>  
>  /*
>   *  protocol version
> -- 
> 2.1.4
> 

[PATCH 39/45] include/uapi/sound/asequencer.h: include sound/asound.h

[Mikko Rapeli]

Fixes userspace compilation error:
error: unknown type name ‘snd_seq_client_type_t’
snd_seq_client_type_t type; /* client type */

Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
---
 include/uapi/sound/asequencer.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h
index 09c8a00..5a5fa49 100644
--- a/include/uapi/sound/asequencer.h
+++ b/include/uapi/sound/asequencer.h
@@ -22,6 +22,7 @@
 #ifndef _UAPI__SOUND_ASEQUENCER_H
 #define _UAPI__SOUND_ASEQUENCER_H
 
+#include <sound/asound.h>
 
 /** version of the sequencer */
 #define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
-- 
2.1.4

Re: [PATCH 39/45] include/uapi/sound/asequencer.h: include sound/asound.h

[Takashi Iwai]

At Tue, 17 Feb 2015 00:05:42 +0100,
Mikko Rapeli wrote:
> 
> Fixes userspace compilation error:
> error: unknown type name ‘snd_seq_client_type_t’
> snd_seq_client_type_t type; /* client type */
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/asequencer.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h
> index 09c8a00..5a5fa49 100644
> --- a/include/uapi/sound/asequencer.h
> +++ b/include/uapi/sound/asequencer.h
> @@ -22,6 +22,7 @@
>  #ifndef _UAPI__SOUND_ASEQUENCER_H
>  #define _UAPI__SOUND_ASEQUENCER_H
>  
> +#include <sound/asound.h>
>  
>  /** version of the sequencer */
>  #define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
> -- 
> 2.1.4
> 

[PATCH 40/45] include/uapi/sound/emu10k1.h: include sound/asound.h

[Mikko Rapeli]

Fixes userspace compilation errors like:
error: field ‘id’ has incomplete type
struct snd_ctl_elem_id id;  /* full control ID definition */

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/sound/emu10k1.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
index d1bbaf7..ec1535b 100644
--- a/include/uapi/sound/emu10k1.h
+++ b/include/uapi/sound/emu10k1.h
@@ -23,8 +23,7 @@
 #define _UAPI__SOUND_EMU10K1_H
 
 #include <linux/types.h>
-
-
+#include <sound/asound.h>
 
 /*
  * ---- FX8010 ----
-- 
2.1.4

Re: [PATCH 40/45] include/uapi/sound/emu10k1.h: include sound/asound.h

[Takashi Iwai]

At Tue, 17 Feb 2015 00:05:43 +0100,
Mikko Rapeli wrote:
> 
> Fixes userspace compilation errors like:
> error: field ‘id’ has incomplete type
> struct snd_ctl_elem_id id;  /* full control ID definition */
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/emu10k1.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
> index d1bbaf7..ec1535b 100644
> --- a/include/uapi/sound/emu10k1.h
> +++ b/include/uapi/sound/emu10k1.h
> @@ -23,8 +23,7 @@
>  #define _UAPI__SOUND_EMU10K1_H
>  
>  #include <linux/types.h>
> -
> -
> +#include <sound/asound.h>
>  
>  /*
>   * ---- FX8010 ----
> -- 
> 2.1.4
> 

[PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Mikko Rapeli]

The DECLARE_BITMAP macro is not available in userspace headers.
Fixes userspace compile error:
error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/sound/emu10k1.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
index ec1535b..f2fd870 100644
--- a/include/uapi/sound/emu10k1.h
+++ b/include/uapi/sound/emu10k1.h
@@ -300,7 +300,9 @@ struct snd_emu10k1_fx8010_control_old_gpr {
 struct snd_emu10k1_fx8010_code {
 	char name[128];
 
+#ifdef __KERNEL__
 	DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
+#endif
 	__u32 __user *gpr_map;		/* initializers */
 
 	unsigned int gpr_add_control_count; /* count of GPR controls to add/replace */
@@ -313,11 +315,15 @@ struct snd_emu10k1_fx8010_code {
 	unsigned int gpr_list_control_total; /* total count of GPR controls */
 	struct snd_emu10k1_fx8010_control_gpr __user *gpr_list_controls; /* listed GPR controls */
 
+#ifdef __KERNEL__
 	DECLARE_BITMAP(tram_valid, 0x100); /* bitmask of valid initializers */
+#endif
 	__u32 __user *tram_data_map;	  /* data initializers */
 	__u32 __user *tram_addr_map;	  /* map initializers */
 
+#ifdef __KERNEL__
 	DECLARE_BITMAP(code_valid, 1024); /* bitmask of valid instructions */
+#endif
 	__u32 __user *code;		  /* one instruction - 64 bits */
 };
 
-- 
2.1.4

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Takashi Iwai]

At Tue, 17 Feb 2015 00:05:44 +0100,
Mikko Rapeli wrote:
> 
> The DECLARE_BITMAP macro is not available in userspace headers.
> Fixes userspace compile error:
> error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’

It's nonsense.  This results in an incompatible structure, thus ABI
would be broken completely (actually this will break the compile of
ld10k1).


Takashi

> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> ---
>  include/uapi/sound/emu10k1.h | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
> index ec1535b..f2fd870 100644
> --- a/include/uapi/sound/emu10k1.h
> +++ b/include/uapi/sound/emu10k1.h
> @@ -300,7 +300,9 @@ struct snd_emu10k1_fx8010_control_old_gpr {
>  struct snd_emu10k1_fx8010_code {
>  	char name[128];
>  
> +#ifdef __KERNEL__
>  	DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
> +#endif
>  	__u32 __user *gpr_map;		/* initializers */
>  
>  	unsigned int gpr_add_control_count; /* count of GPR controls to add/replace */
> @@ -313,11 +315,15 @@ struct snd_emu10k1_fx8010_code {
>  	unsigned int gpr_list_control_total; /* total count of GPR controls */
>  	struct snd_emu10k1_fx8010_control_gpr __user *gpr_list_controls; /* listed GPR controls */
>  
> +#ifdef __KERNEL__
>  	DECLARE_BITMAP(tram_valid, 0x100); /* bitmask of valid initializers */
> +#endif
>  	__u32 __user *tram_data_map;	  /* data initializers */
>  	__u32 __user *tram_addr_map;	  /* map initializers */
>  
> +#ifdef __KERNEL__
>  	DECLARE_BITMAP(code_valid, 1024); /* bitmask of valid instructions */
> +#endif
>  	__u32 __user *code;		  /* one instruction - 64 bits */
>  };
>  
> -- 
> 2.1.4
> 

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Mikko Rapeli]

On Tue, Feb 17, 2015 at 07:27:38AM +0100, Takashi Iwai wrote:
> At Tue, 17 Feb 2015 00:05:44 +0100,
> Mikko Rapeli wrote:
> > 
> > The DECLARE_BITMAP macro is not available in userspace headers.
> > Fixes userspace compile error:
> > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> 
> It's nonsense.  This results in an incompatible structure, thus ABI
> would be broken completely (actually this will break the compile of
> ld10k1).

None of the exported headers after 'make headers_install' have definition
of DECLARE_BITMAP macro. It is defined in include/linux/types.h which is
different from include/uapi/linux/types.h and missing this definition and
a few other things.

One option would be add DECLARE_BITMAP macro to include/uapi/linux/types.h
and add include/linux/bitops.h to uapi.

Thoughts?

-Mikko

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Takashi Iwai]

At Wed, 11 Mar 2015 03:22:04 +0200,
Mikko Rapeli wrote:
> 
> On Tue, Feb 17, 2015 at 07:27:38AM +0100, Takashi Iwai wrote:
> > At Tue, 17 Feb 2015 00:05:44 +0100,
> > Mikko Rapeli wrote:
> > > 
> > > The DECLARE_BITMAP macro is not available in userspace headers.
> > > Fixes userspace compile error:
> > > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> > 
> > It's nonsense.  This results in an incompatible structure, thus ABI
> > would be broken completely (actually this will break the compile of
> > ld10k1).
> 
> None of the exported headers after 'make headers_install' have definition
> of DECLARE_BITMAP macro. It is defined in include/linux/types.h which is
> different from include/uapi/linux/types.h and missing this definition and
> a few other things.
> 
> One option would be add DECLARE_BITMAP macro to include/uapi/linux/types.h
> and add include/linux/bitops.h to uapi.
> 
> Thoughts?

Are there any other headers like that?  If this is the only one, leave
it as is.  The only program that reads this are some alsa-tools ones
and they have already own DECLARE_BITMAP() definition.  Adding the
extra definition here will even break the compilation out of sudden.


Takashi

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Arnd Bergmann]

On Wednesday 11 March 2015 07:11:18 Takashi Iwai wrote:
> At Wed, 11 Mar 2015 03:22:04 +0200,
> Mikko Rapeli wrote:
> > 
> > On Tue, Feb 17, 2015 at 07:27:38AM +0100, Takashi Iwai wrote:
> > > At Tue, 17 Feb 2015 00:05:44 +0100,
> > > Mikko Rapeli wrote:
> > > > 
> > > > The DECLARE_BITMAP macro is not available in userspace headers.
> > > > Fixes userspace compile error:
> > > > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> > > 
> > > It's nonsense.  This results in an incompatible structure, thus ABI
> > > would be broken completely (actually this will break the compile of
> > > ld10k1).
> > 
> > None of the exported headers after 'make headers_install' have definition
> > of DECLARE_BITMAP macro. It is defined in include/linux/types.h which is
> > different from include/uapi/linux/types.h and missing this definition and
> > a few other things.
> > 
> > One option would be add DECLARE_BITMAP macro to include/uapi/linux/types.h
> > and add include/linux/bitops.h to uapi.
> > 
> > Thoughts?
> 
> Are there any other headers like that?  If this is the only one, leave
> it as is.  The only program that reads this are some alsa-tools ones
> and they have already own DECLARE_BITMAP() definition.  Adding the
> extra definition here will even break the compilation out of sudden.

I think it's a worthy goal to have the header files be compilable
standalone, but I don't think we should make the DECLARE_BITMAP()
macro globally visible in user space, in particular because it will
clash with every instance in which user space has a macro of the
same name.

What we could do here is to add a private copy of the macro to emu10k1.h
under a different name, such as __EMU10K1_DECLARE_BITMAP().

	Arnd

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Takashi Iwai]

At Wed, 11 Mar 2015 10:46:29 +0100,
Arnd Bergmann wrote:
> 
> On Wednesday 11 March 2015 07:11:18 Takashi Iwai wrote:
> > At Wed, 11 Mar 2015 03:22:04 +0200,
> > Mikko Rapeli wrote:
> > > 
> > > On Tue, Feb 17, 2015 at 07:27:38AM +0100, Takashi Iwai wrote:
> > > > At Tue, 17 Feb 2015 00:05:44 +0100,
> > > > Mikko Rapeli wrote:
> > > > > 
> > > > > The DECLARE_BITMAP macro is not available in userspace headers.
> > > > > Fixes userspace compile error:
> > > > > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> > > > 
> > > > It's nonsense.  This results in an incompatible structure, thus ABI
> > > > would be broken completely (actually this will break the compile of
> > > > ld10k1).
> > > 
> > > None of the exported headers after 'make headers_install' have definition
> > > of DECLARE_BITMAP macro. It is defined in include/linux/types.h which is
> > > different from include/uapi/linux/types.h and missing this definition and
> > > a few other things.
> > > 
> > > One option would be add DECLARE_BITMAP macro to include/uapi/linux/types.h
> > > and add include/linux/bitops.h to uapi.
> > > 
> > > Thoughts?
> > 
> > Are there any other headers like that?  If this is the only one, leave
> > it as is.  The only program that reads this are some alsa-tools ones
> > and they have already own DECLARE_BITMAP() definition.  Adding the
> > extra definition here will even break the compilation out of sudden.
> 
> I think it's a worthy goal to have the header files be compilable
> standalone,

In general yes, but this case is very minor issue:
- the file in question is for a hardware device-specific data
  definition,
- there are only two programs read this file, both can be built
  properly,
- and the device and the programs are very old, modifying such need
  extra care.

> but I don't think we should make the DECLARE_BITMAP()
> macro globally visible in user space, in particular because it will
> clash with every instance in which user space has a macro of the
> same name.
> 
> What we could do here is to add a private copy of the macro to emu10k1.h
> under a different name, such as __EMU10K1_DECLARE_BITMAP().

Yes, it's a better option.


thanks,

Takashi

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Arnd Bergmann]

On Thursday 12 March 2015 07:11:48 Takashi Iwai wrote:
> At Wed, 11 Mar 2015 10:46:29 +0100,
> Arnd Bergmann wrote:
> > 
> > On Wednesday 11 March 2015 07:11:18 Takashi Iwai wrote:
> > > At Wed, 11 Mar 2015 03:22:04 +0200,
> > > 
> > > Are there any other headers like that?  If this is the only one, leave
> > > it as is.  The only program that reads this are some alsa-tools ones
> > > and they have already own DECLARE_BITMAP() definition.  Adding the
> > > extra definition here will even break the compilation out of sudden.
> > 
> > I think it's a worthy goal to have the header files be compilable
> > standalone,
> 
> In general yes, but this case is very minor issue:
> - the file in question is for a hardware device-specific data
>   definition,
> - there are only two programs read this file, both can be built
>   properly,
> - and the device and the programs are very old, modifying such need
>   extra care.

Right, we should only do it if the goal is to have all uapi headers
includable standalone. For a particular header file there is very
little benefit as you say, but it would be useful if we can automatically
test for regressions with new or modified headers.

	Arnd

Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

[Takashi Iwai]

At Thu, 12 Mar 2015 09:45:42 +0100,
Arnd Bergmann wrote:
> 
> On Thursday 12 March 2015 07:11:48 Takashi Iwai wrote:
> > At Wed, 11 Mar 2015 10:46:29 +0100,
> > Arnd Bergmann wrote:
> > > 
> > > On Wednesday 11 March 2015 07:11:18 Takashi Iwai wrote:
> > > > At Wed, 11 Mar 2015 03:22:04 +0200,
> > > > 
> > > > Are there any other headers like that?  If this is the only one, leave
> > > > it as is.  The only program that reads this are some alsa-tools ones
> > > > and they have already own DECLARE_BITMAP() definition.  Adding the
> > > > extra definition here will even break the compilation out of sudden.
> > > 
> > > I think it's a worthy goal to have the header files be compilable
> > > standalone,
> > 
> > In general yes, but this case is very minor issue:
> > - the file in question is for a hardware device-specific data
> >   definition,
> > - there are only two programs read this file, both can be built
> >   properly,
> > - and the device and the programs are very old, modifying such need
> >   extra care.
> 
> Right, we should only do it if the goal is to have all uapi headers
> includable standalone. For a particular header file there is very
> little benefit as you say, but it would be useful if we can automatically
> test for regressions with new or modified headers.

True.  Yet another option would be just move this file back from
include/uapi/sound to include/sound.  Basically no user-space programs
care about this file, as they have already a copy of old header fils
in the package.

But maybe defining __EMU10K1_DECLARE_BITMAP() would be the easiest
solution, I suppose.


thanks,

Takashi