On Mon, Aug 30, 2004 at 09:08:07PM -0700, Linus Torvalds wrote:
> > 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".
Well, I'd call that userspace (if it has a pid and it's own addr space, like
every other proc).
> 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.
Just out of curiousity, what do you think of L4? I don't remember the
numbers, but it wasn't much slower than linux (iirc), even on x86. I think
k42 has msg passing close to the speed of a syscall. (Bulk data could use
shared mem, maybe.)
Anyway, it would be neat to have a tcp/ip daemon. You could run experimental
code w/o fear of it clobbering other things. Somethings, of course, a
microkernel can't help (if the rootfs's fs daemon dies, you're screwed). A
little bit more containment from bad kernel code would be nice.
(BTW, for those who don't know, mach optimized away msg passing and used a
single addr space, once code was "trusted". You could choose speed over
protection. That wasn't a hard choice since Mach msg passing sucks. Mach
gave microkernels a bad name.)
> 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.
How are they different from regular user procs, other then being trusted to
manage certain resources?
> 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.
Exokernels are another topic. 8)
> > 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.
Yes it is, it's a user process.
> Well, performance might still suck, of course. And it does.
--
Tom Vier <[email protected]>
DSA Key ID 0x15741ECE
On Thu, 2 Sep 2004, Tom Vier wrote:
>
> > 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.
>
> How are they different from regular user procs, other then being trusted to
> manage certain resources?
Ehh, they are separate the same way "inetd" is separate. It's not a _user_
proc, it's a system proc. The user can't actually do anything about it.
In many ways UNIX _is_ a microkernel. It does nonessential stuff in "user
space". Anything that is critical for performance or the working of the
machine is in kernel space.
The big difference between UNIX and what people _call_ "microkernels" is
that UNIX has a very functional and sane partitioning of what is a
critical thing.
But from a kernel _protection_ angle, the only part that is important is
that the services be in some protected domain. That was what started this
discussion: 99% of what the kernel does is protecting shared data. Whether
it does so by passing it on to some trusted third party or not is an
implementation issue, and is totally pointless from a user standpoint,
since the user won't see it anyway.
Linus