Re: cdrtools cdrecord/cdrecord.c
On Mon, Jan 23, 2006 at 06:26:35PM +0100, Joerg Schilling wrote:
> 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.
> > > 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
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.