mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* 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

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®