Re: cdrtools cdrecord/cdrecord.c

[Bill Davidsen <davidsen@tmr.com>]

Joerg Schilling wrote:

> Ville Syrjälä <syrjala@sci.fi> wrote:
>
>  
>
> > On Mon, Jan 23, 2006 at 03:41:16PM +0100, Joerg Schilling wrote:
> >    
> >
> > > Geoffrey <esoteric@3times25.net> 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.
> > > 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.
> > >      
> > 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.
> >    
>
> 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.
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.

--
bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979