Re: cdrtools cdrecord/cdrecord.c
Joerg Schilling wrote:
Hogwash. There is a set of includes for each kernel, or subset of
kernels sharing headers, and you use that and make the user specify the
location. It's easier than making the user patch your broken build
tools. There is no directory /usr/src/linux on most systems, it's only
used for kernel development. You are counting on something which has not
been commonly present for a decade.
Ville Syrjälä <firstname.lastname@example.org> wrote:
On Mon, Jan 23, 2006 at 03:41:16PM +0100, Joerg Schilling wrote:
Geoffrey <email@example.com> wrote:
I am not against Linux, however I don't like the way the Linux kernel developers
personally attack people who tell them where they make mistakes.
Let me make an example: if you take Linus Torvalds statements on Linux kernel
include files for serious, then it is _forbidden_ to test kernel interfaces.
Well, first note that glibc does not even know about most kernel interfaces,
the include files that come with glibc are much older than the linux kernel.
Whose preventing you from testing it? For your testing you can do
anything you like. However when distributing the program it would help
the distro people if you just used the standard /usr/include path.
If I add a new interface to the linux kernel today or if I enhance an old one,
I cannot test it in case I am only allowed to use the include files from glibc.
You did not understand it:
- If you need to break a rule on a regular base it is nonsense.
- Linux decided to _need_ /usr/src/linux/unclude in the search PATH.
It was needed for Linux-2.2 or earlier and such a decision cannot
ever be changed later.
bill davidsen <firstname.lastname@example.org>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979