Messages in this thread | | | Date | Tue, 31 Aug 2004 23:13:31 +0200 | From | Frank van Maarseveen <> | Subject | Re: silent semantic changes with reiser4 |
| |
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/
| |