[PATCH] headers_check: special case seqbuf_dump()

[PATCH] headers_check: special case seqbuf_dump()

[Paul Bolle]

"make headers_check" warns about soundcard.h for (at least) five years
now:
    [...]/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernel

We're apparently stuck with providing OSSlib-3.8 compatibility, so let's
special case this declaration just to silence it.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Support for OSSlib post 3.8 was already removed in commit 43a990765a
("sound: Remove OSSlib stuff from linux/soundcard.h"). Five years have
passed since that commit: do people still care about OSSlib-3.8? If not,
quite a bit of code could be remove from soundcard.h (and probably
ultrasound.h).

2) By the way, what is actually meant by:
    It is no longer possible to actually link against OSSlib with this
    header, but we still provide these macros for programs using them.

Doesn't that mean compatibility to OSSlib isn't even useful?

3) Anyhow, a previous discussion soundcard.h, which led to that commit,
starts at https://lkml.org/lkml/2009/1/20/349 .

4) And, yes, I sneaked in a whitespace fix.

 scripts/headers_check.pl | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
index 64ac238..62320f9 100644
--- a/scripts/headers_check.pl
+++ b/scripts/headers_check.pl
@@ -65,7 +65,11 @@ sub check_include
 
 sub check_declarations
 {
-	if ($line =~m/^(\s*extern|unsigned|char|short|int|long|void)\b/) {
+	# soundcard.h is what it is
+	if ($line =~ m/^void seqbuf_dump\(void\);/) {
+		return;
+	}
+	if ($line =~ m/^(\s*extern|unsigned|char|short|int|long|void)\b/) {
 		printf STDERR "$filename:$lineno: " .
 			      "userspace cannot reference function or " .
 			      "variable defined in the kernel\n";
-- 
1.8.4.2

Re: [PATCH] headers_check: special case seqbuf_dump()

[Arnd Bergmann]

On Wednesday 15 January 2014, Paul Bolle wrote:
> "make headers_check" warns about soundcard.h for (at least) five years
> now:
>     [...]/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernel
> 
> We're apparently stuck with providing OSSlib-3.8 compatibility, so let's
> special case this declaration just to silence it.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

Thanks so much! This one has been bugging me for ages.

Acked-by: Arnd Bergmann <arnd@arndb.de>

Who would be the right person to apply this? Adding Andrew and Michal
to Cc.

Re: [PATCH] headers_check: special case seqbuf_dump()

[Takashi Iwai]

At Wed, 15 Jan 2014 11:48:19 +0100,
Paul Bolle wrote:
> 
> "make headers_check" warns about soundcard.h for (at least) five years
> now:
>     [...]/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernel
> 
> We're apparently stuck with providing OSSlib-3.8 compatibility, so let's
> special case this declaration just to silence it.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Support for OSSlib post 3.8 was already removed in commit 43a990765a
> ("sound: Remove OSSlib stuff from linux/soundcard.h"). Five years have
> passed since that commit: do people still care about OSSlib-3.8? If not,
> quite a bit of code could be remove from soundcard.h (and probably
> ultrasound.h).

Such a thing is always hard to know, just like to find a Bigfoot :)

> 2) By the way, what is actually meant by:
>     It is no longer possible to actually link against OSSlib with this
>     header, but we still provide these macros for programs using them.
> 
> Doesn't that mean compatibility to OSSlib isn't even useful?

Well, it's not about the compatibility to osslib.  The OSS seq
user-space codes are written with these macros no matter whether to
use osslib or not.  osslib was newer than these macros and it was
designed to be compatible with them.


thanks,

Takashi


> 3) Anyhow, a previous discussion soundcard.h, which led to that commit,
> starts at https://lkml.org/lkml/2009/1/20/349 .
> 
> 4) And, yes, I sneaked in a whitespace fix.
> 
>  scripts/headers_check.pl | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
> index 64ac238..62320f9 100644
> --- a/scripts/headers_check.pl
> +++ b/scripts/headers_check.pl
> @@ -65,7 +65,11 @@ sub check_include
>  
>  sub check_declarations
>  {
> -	if ($line =~m/^(\s*extern|unsigned|char|short|int|long|void)\b/) {
> +	# soundcard.h is what it is
> +	if ($line =~ m/^void seqbuf_dump\(void\);/) {
> +		return;
> +	}
> +	if ($line =~ m/^(\s*extern|unsigned|char|short|int|long|void)\b/) {
>  		printf STDERR "$filename:$lineno: " .
>  			      "userspace cannot reference function or " .
>  			      "variable defined in the kernel\n";
> -- 
> 1.8.4.2
> 

Re: [PATCH] headers_check: special case seqbuf_dump()

[Paul Bolle]

On Thu, 2014-01-16 at 12:53 +0100, Takashi Iwai wrote:
> At Wed, 15 Jan 2014 11:48:19 +0100,
> Paul Bolle wrote:
> > 2) By the way, what is actually meant by:
> >     It is no longer possible to actually link against OSSlib with this
> >     header, but we still provide these macros for programs using them.
> > 
> > Doesn't that mean compatibility to OSSlib isn't even useful?
> 
> Well, it's not about the compatibility to osslib.  The OSS seq
> user-space codes are written with these macros no matter whether to
> use osslib or not.  osslib was newer than these macros and it was
> designed to be compatible with them.

So perhaps that line should read something like:
    [...]
    header, but we still provide these macros for programs that want to
    interface with /dev/dsp and /dev/sequencer directly.

I'm making that up: I know nothing about this stuff. I'm just looking
for a way to make that comment clear to a person that wonders in, say,
2019: "What on earth is seqbuf_dump() good for?".


Paul Bolle

Re: [PATCH] headers_check: special case seqbuf_dump()

[Takashi Iwai]

At Thu, 16 Jan 2014 13:39:24 +0100,
Paul Bolle wrote:
> 
> On Thu, 2014-01-16 at 12:53 +0100, Takashi Iwai wrote:
> > At Wed, 15 Jan 2014 11:48:19 +0100,
> > Paul Bolle wrote:
> > > 2) By the way, what is actually meant by:
> > >     It is no longer possible to actually link against OSSlib with this
> > >     header, but we still provide these macros for programs using them.
> > > 
> > > Doesn't that mean compatibility to OSSlib isn't even useful?
> > 
> > Well, it's not about the compatibility to osslib.  The OSS seq
> > user-space codes are written with these macros no matter whether to
> > use osslib or not.  osslib was newer than these macros and it was
> > designed to be compatible with them.
> 
> So perhaps that line should read something like:
>     [...]
>     header, but we still provide these macros for programs that want to
>     interface with /dev/dsp and /dev/sequencer directly.

The macros are only for /dev/sequencer (and its variants).

> I'm making that up: I know nothing about this stuff. I'm just looking
> for a way to make that comment clear to a person that wonders in, say,
> 2019: "What on earth is seqbuf_dump() good for?".

I don't think rephrasing like the above would give a better answer...


Takashi