![]() | |||||||||||||
Messages in this thread |
On Mon, 30 Aug 2004, Tom Vier wrote: > On Thu, Aug 26, 2004 at 09:48:04AM -0700, Linus Torvalds wrote: > > - safely synchronize globally visible data structures > > That's quite fundamental. 99% of what a kernel does is exactly that. TCP > > would be in user space too, if it wasn't for _exactly_ this issue. A lot > > What about microkernels? They do tcp in userspace. No they don't. They do TCP in a separate address space from user space, that just also happens to be separate from the "microkernel address space". So a microkernel will have _more_ address spaces, and they won't be "user space". They'll be "server deamon space" or something. Now, that's also why they tend to have performance problems - because you need to copy the data between different address spaces, and switch the CPU context etc around. Not user space. They may be "ring 3" from a CPU standpoint, but they aren't user space from a _user_ standpoint - it's still very much a separate address space, with domain protection. > So did winsock, iirc. Now that is a different case. Things like the PalmOS TCP stack (and, I believe, Winsock) are true "user space" TCP stacks, in that they really do live as libraries in the same address space as the user app. It sucks. Exactly because now the data structures are _not_ protected, and they are _not_ shared. So your library basically ends up being a "single client" library, with no protection between clients (or no sharing: you can have "protected" single-stream TCP, but then you won't share the TCP state that needs to be shared like listen queues etc). This works in an environment like Palm or Win-3.0, which are really just single-client _anyway_, without any protection. But notice how Windows started doing TCP in the kernel, and notice how you can actually use it as a server these days? In short: you _need_ to have a separate address space (either kernel, or "TCP server" or whatever) if you want to have reliable, secure and generally usable TCP. > As long as a trusted process keeps data such as free ports, what's the > problem? None - because it's not user space any more. Well, performance might still suck, of course. And it does. 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/ | ||||||||||||
| Last update: 2005-03-22 14:05 [from the cache] ©2003-2008 | |||||||||||||