Re: silent semantic changes with reiser4

From: Frank van Maarseveen (frankvm_at_xs4all.nl)
Date: 08/31/04

  • Next message: William Lee Irwin III: "[3/2] document wake_up_bit()'s requirement for preceding memory barriers" 
    Date:	Tue, 31 Aug 2004 23:13:31 +0200
To: Linus Torvalds <torvalds@osdl.org>

    On Tue, Aug 31, 2004 at 10:15:25AM -0700, Linus Torvalds wrote:
    >
    > Admins absolutely _hate_ that. They will ban an OS if it sends out packets
    > that cause troublem. You should remember that - we used to do strange
    > things on the net (long long time ago), and we brought down servers by
    > mistake, and nobody ever considered it a server bug: it was a Linux bug
    > that it wouldn't do the right thing.
    >
    > Things like not sending FIN-packets when a program suddenly goes away is
    > NOT acceptable behaviour! Neither is it acceptable behaviour to allow user
    > programs to make up their own packets.

    The user/kernel distinction is not always (heck, maybe almost never)
    present in the embedded world (a large world). The notion of a "regular
    user" does not apply at all in such a case. This is not a bug but merely
    the state of technology. It will slowly go away I think because embedded
    software becomes more complex and hardware becomes cheaper.

    To implement multiple TCP clients _and_ the TCP/IP stack in one space is
    perfectly possible and it's actually done in practice. It has advantages
    (speed, when done properly) and disadvantages (complexity/bug-prone).

    >
    > NOTE! This is totally ignoring the fact that you can't be called "UNIX"
    > any more. You _need_ to have sequence numbers etc be shared between
    > multiple programs that all write to the stream. Again, that _does_ mean
    > that you have another protection domain (aka "kernel" or "TCP deamon")
    > that keeps track of the sequence number.

    There is nothing in the networking or UNIX standards that prescibe another
    protection domain for this. Would be insane to leave that out in a hosted
    environment but it _can_ be done without. 

    -- 
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: William Lee Irwin III: "[3/2] document wake_up_bit()'s requirement for preceding memory barriers"

    Relevant Pages

    • Re: AGP problem SiS 746FX Linux 2.6.5-rc3
      ... the Empire squashes the Federation like a bug. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.9bk6 msdos fs OOPS
      ... >This bug is triggered by race condition. ... Apparently my lashup doesn't trigger it. ... Copyright 2004 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks
      ... BUG: Unable to handle kernel NULL pointer dereference at virtual address ... TAS_BUFFER_FNS(RevokeValid, revokevalid) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: BUG at mm/memory.c:1501 in 2.6.0-test5
      ... >Any module running inside the kernel can destroy anything. ... A simple bug in any ... You should send your report to the vendor. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: kernel BUG at page_alloc.c
      ... Marcelo Tosatti wrote: ... > Its the third or fourth report like this I see, ... CONFIG_GRKERNSEC_PAX_MPROTECT) and i don't remember seeing such BUG... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)