[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cdrtools cdrecord/cdrecord.c



On Mon, Jan 23, 2006 at 06:26:35PM +0100, 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.

I actually agree that it would be nice to have clean public kernel 
headers that would be used by both userspace and kernel. But that's not 
how it works.

> -	Linux decided to _need_ /usr/src/linux/unclude in the search PATH.
> 	It was needed for Linux-2.2 or earlier 

I'm pretty sure that would be 2.0 or earlier.

> and such a decision cannot
> 	ever be changed later.

It was changed seven years ago.

> > I did find one message from you where you said some operations were 
> > impossible due to the filter but when asked for a list of required 
> > commands you did not respond.
> 
> I send a list and I told them that this list is a constand subject to change.
> Then the LKLM folks stopped to be reasonable 

I couldn't find such a list in lkml archives. I do understand that the 
approach has it's problems but unless you change cdrecord not to drop 
CAP_SYS_RAWIO I don't think there's a good alternative.

> > Other than that I've only seen you give vague references to Linux bugs 
> > but no useful bug reports.
> 
> I do never _repeat_ long descriptions I send before. 
> 
> 
> NOTE: it turns out that you are not helpful at all and only like to waste my 
> time.

Wasting your time is actually my day job.

> Unless you are able to help with the problems please stop your postings.

I'm starting to think you're beyond help.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/



Reply to: