* Request to stop cdrecord's bogus accusations of Linux.
@ 2006-01-30 17:37 Matthias Andree
2006-01-30 17:47 ` Joerg Schilling
0 siblings, 1 reply; 3+ messages in thread
From: Matthias Andree @ 2006-01-30 17:37 UTC (permalink / raw)
To: Joerg Schilling; +Cc: Linux-Kernel mailing list, cdwrite
Jörg,
with this open letter, I officially request that you stop your
misrepresentations in cdrecord that claim Linux were noncompliant in a
place where it is conforming to POSIX.
I am not speaking on behalf of any other party here, this is purely my
personal opinion that is supposed to make sure both sides play fair.
<ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a05>
(dated 2006-01-29 20:20" states
"- Trying to work around a noncompliance (modified interface) present
on newer Linux kernels that causes cdrecord to be unable to allocate a
SCSI transfer buffer.
Newer Linux kernels do not honor a contract from mlockall(MCL_FUTURE)
after cdrecord turned off euid == 0 from a suid root installation.
Instead of honoring mlockall(MCL_FUTURE), Linux checks each mmap() and
compares against getrlimit(RLIMIT_MEMLOCK"
There is no such contract that would promise future allocations to
always succeed after MCL_FUTURE.
POSIX explicitly allows operating systems to fail later allocations if
the limit of mappable memory exceeds a certain limit, quoting the
mlockall() description from IEEE Std 1003.1-2001, 2004 edition:
"If MCL_FUTURE is specified, and the automatic locking of future
mappings eventually causes the amount of locked memory to exceed the
| amount of available physical memory or any other
| implementation-defined limit, the behavior is implementation-defined.
| The manner in which the implementation informs the application of
| these situations is also implementation-defined."
Linux is therefore POSIX compliant here. MCL_FUTURE succeeds and the
RLIMIT_MEMLOCK interface that you are whining about is this
"implementation-defined limit", and the implementation-defined behavior
refusing the allocation.
You had been told much earlier in linux-kernel@ that Linux is POSIX
compliant here, yet your document repeats this slander.
You are correct that Linux changed behavior beginning with release
2.6.9, but that change does not make Linux noncompliant with applicable
standards. I suggest to reword the quoted paragraph as
"Working around a new behavior in Linux since 2.6.9 that causes
cdrecord to be unable to allocate a SCSI transfer buffer.
These Linux kernel versions impose a tighter RLIMIT_MEMLOCK limit
than earlier versions that cause the allocation failure."
--
Matthias Andree
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Request to stop cdrecord's bogus accusations of Linux.
2006-01-30 17:37 Request to stop cdrecord's bogus accusations of Linux Matthias Andree
@ 2006-01-30 17:47 ` Joerg Schilling
2006-01-30 18:03 ` Matthias Andree
0 siblings, 1 reply; 3+ messages in thread
From: Joerg Schilling @ 2006-01-30 17:47 UTC (permalink / raw)
To: schilling, matthias.andree; +Cc: linux-kernel, cdwrite
Matthias Andree <matthias.andree@gmx.de> wrote:
> with this open letter, I officially request that you stop your
> misrepresentations in cdrecord that claim Linux were noncompliant in a
> place where it is conforming to POSIX.
>
> I am not speaking on behalf of any other party here, this is purely my
> personal opinion that is supposed to make sure both sides play fair.
>
> <ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a05>
> (dated 2006-01-29 20:20" states
I am sorry to see that you still insist in claiming things that are not in this
announcement.
You did inform me about this Linux "self non-compliance" and you are the only
person who did claim that there is a problem. I spend a lot of time in trying
to find a work around for this problem and I am in hope that I did find a
working solution.
Please stop claiming things I did never write!
I did never mention that this was a POSIX non-compliance, this is entirely from
your imagination. I rather mentioned that this is a problem caused by the fact
that Linux changed it's behavior in a way that breaks existing applications.
For this reason it is apropriate to call the code that deals with the problem
"a workaround".
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Request to stop cdrecord's bogus accusations of Linux.
2006-01-30 17:47 ` Joerg Schilling
@ 2006-01-30 18:03 ` Matthias Andree
0 siblings, 0 replies; 3+ messages in thread
From: Matthias Andree @ 2006-01-30 18:03 UTC (permalink / raw)
To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, cdwrite
Joerg Schilling schrieb am 2006-01-30:
> Matthias Andree <matthias.andree@gmx.de> wrote:
>
> > with this open letter, I officially request that you stop your
> > misrepresentations in cdrecord that claim Linux were noncompliant in a
> > place where it is conforming to POSIX.
> >
> > I am not speaking on behalf of any other party here, this is purely my
> > personal opinion that is supposed to make sure both sides play fair.
> >
> > <ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a05>
> > (dated 2006-01-29 20:20" states
>
> I am sorry to see that you still insist in claiming things that are not in this
> announcement.
>
> You did inform me about this Linux "self non-compliance" and you are the only
> person who did claim that there is a problem. I spend a lot of time in trying
> to find a work around for this problem and I am in hope that I did find a
> working solution.
Compliance is a term used in contexts such as "standards" compliance.
Even "self compliance" is given, the Linux manpage matches observed
behavior, too.
Fact however is that I approached you with a patch that moved the
allocation into root-mode code, and later with a patch that reset
RLIMIT_MEMLOCK to RLIM_INFINITY, and we tested several variants forth
and back until you settled for raising RLIMIT_MEMLOCK to some 6 MB.
...
> For this reason it is apropriate to call the code that deals with the problem
> "a workaround".
Which was not at all my point, but "compliance" is. I don't mind you
calling it workaround or call 2.6.9 incompatible with 2.6.8.1.
Re-read my message - and I find it interesting to read this NOW, after
I'd mailed this and discussed this earlier.
--
Matthias Andree
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-01-30 18:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-30 17:37 Request to stop cdrecord's bogus accusations of Linux Matthias Andree
2006-01-30 17:47 ` Joerg Schilling
2006-01-30 18:03 ` Matthias Andree
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®