In <Pine.WNT.4.21.0003131212030.214-100000@8938cs820195.ied.cpqcorp.net> Paul Jakma (paul.jakma@compaq.com) wrote:
PJ> On Mon, 13 Mar 2000, Khimenko Victor wrote:
>> P.S. You can all it any way you want but it's sad truth: syslogd, klogd, named
>> and LOTS and LOTS of other daemons will die if malloc will return ENOMEM.
>> Welcome to real world from your ivory tower :-)
>>
PJ> then they should be fixed...
Do you volunteer ?
PJ> linux has never been afraid of calling a spade a spade.
This is true.
PJ> And it has never gone out of its way to support bad apps.
Quite untrue. If app is important enough or if there are numerous important
apps then changes are done to support them. Even if it's against POSIX and
even if it's "not right in ideal world". Linus's letter just few days ago:
-- cut --
On Sat, 11 Mar 2000, Artur Skawina wrote:
>
> no, it doesn't, but i now have a suspect -- bash. [v1.14.5(1) linked w/ libc5]
> why this didn't occur to me when i noticed init=/bin/bash didn't
> work either i have no idea :)
> As i don't see bash using any sysvmem, i'll have to investigate further.
> [were there any changes to mmap() semantics?]
>
> [turns out bash (ie the dynamic linker) gets killed with a SIGBUS, after
> it maps a zero-length "/etc/ld.so.preload"
Ahhah!
This is another change in 2.3.x behaviour: it is a POSIX requirement that
I don't particularly like, but there you have it. Any access past the last
page of a file should give a SIGBUS. Previous Linux behaviour was to just
map in a zero page.
> [ahh, temporarily removing that file finally gives a bootable system.]
I will leave the SIGBUS behaviour, andif this is the only program that
breaks due to new POSIX conformance, I will consider us very lucky indeed.
Finges crossed. If some other major package breaks we will probably have
to forget that particular conformance detail..
Linus
-- cut --
Note last paragraph... Yes, a spade will be called a spade in rude comment
inside kernel but kernel WILL be changed to support spade if this spade
(or spades) is important enough. This was done by Linus zillion times before...
PJ> If crucial system daemons are broken wrt to OOM then they should be fixed,
PJ> not worked-around.
Once again: go and fix them. When you'll return with patches for majority of
them THEN we can sonsider removing OOM hack from kernel. It's quite easy to
say that all daemons should be fixed. It's often not easy to fix them. Yes,
in ideal world all deamons will tolerate ENOMEM. We live in real world, not in
ideal world.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST