From: Matthias Andree <matthias.andree@gmx.de>
To: Joerg Schilling <schilling@fokus.fraunhofer.de>
Cc: Linux-Kernel mailing list <linux-kernel@vger.kernel.org>,
cdwrite@other.debian.org
Subject: Request to stop cdrecord's bogus accusations of Linux.
Date: Mon, 30 Jan 2006 18:37:22 +0100 [thread overview]
Message-ID: <20060130173722.GC3973@merlin.emma.line.org> (raw)
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
next reply other threads:[~2006-01-30 17:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-30 17:37 Matthias Andree [this message]
2006-01-30 17:47 ` Joerg Schilling
2006-01-30 18:03 ` Matthias Andree
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060130173722.GC3973@merlin.emma.line.org \
--to=matthias.andree@gmx.de \
--cc=cdwrite@other.debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schilling@fokus.fraunhofer.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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®