Messages in this thread | | | Date | Tue, 31 Aug 2004 10:15:25 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: silent semantic changes with reiser4 |
| |
On Tue, 31 Aug 2004, Alan Cox wrote: > > Several do TCP in user space. The only thing you need in kernel for > TCP/IP is enough decode to decide who gets the packet.
Only thing? I don't think so.
You also want to make sure that regular users cannot send "impossible" packets. Think about the old "ping of death" kind of thing, where a normal mis-behaving (and I'm not saying intentionally so: it might be a small bug that just overwrites some data) program should _not_ be able to cause problems on the network.
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.
> Even some non microkernel embedded OS's do this in order to keep kernel > size down.
..and I'm not disagreeing that it doesn't happen. I explicitly mentioned PalmOS, I bet it happens in other cases too. But I'd strongly argue that it's a bug, not a feature.
It's a bug that people tend to accept in a "single-client" environment.
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.
Linus - 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/
| |