headers_check: special case seqbuf_dump()
PATCH 1/1 headers_check: special case seqbuf_dump()
"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.
---
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(-)
scripts/headers_check.pl +5 -1
@@ -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";
Signature · 1 line
1.8.4.2
Quoted 8 lines · Paul Bolle
"make
headers_check" warns aboutsoundcard.hfor (at least) five years
now:
[...]/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernelWe'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 <[email protected]>
Thanks so much! This one has been bugging me for ages.
Who would be the right person to apply this? Adding Andrew and Michal to Cc.
At Wed, 15 Jan 2014 11:48:19 +0100,
Quoted 8 lines · Paul Bolle
"make
headers_check" warns aboutsoundcard.hfor (at least) five years
now:
[...]/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernelWe're apparently stuck with providing OSSlib-3.8 compatibility, so let's special case this declaration just to silence it.
Quoted 7 lines
Signed-off-by Paul Bolle <[email protected]>---
0) Support for OSSlib post 3.8 was already removed in commit43a990765a("sound: Remove OSSlib stuff fromlinux/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 fromsoundcard.h(and probablyultrasound.h).
Such a thing is always hard to know, just like to find a Bigfoot :)
Quoted 5 lines
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
Quoted 28 lines
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(-)scripts/headers_check.pl +5
-1@@ -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";Signature · 1 line
1.8.4.2
Quoted 6 lines · Takashi Iwai
At Wed, 15 Jan 2014 11:48:19 +0100,
Quoted 4 lines · Paul Bolle
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.
Quoted 6 lines
Quoted 1 line
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
At Thu, 16 Jan 2014 13:39:24 +0100,
Quoted 15 lines · Paul Bolle
Quoted 6 lines · Takashi Iwai
At Wed, 15 Jan 2014 11:48:19 +0100,
Quoted 4 lines · Paul Bolle
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.Quoted 6 lines
Quoted 1 line
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.
Quoted 4 lines
So perhaps that line should read something like:
[...]
header, but we still provide these macros for programs that want to interface with/dev/dspand/dev/sequencerdirectly.
The macros are only for /dev/sequencer (and its variants).
Quoted 3 lines
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