Index Home About Blog
Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Announce: ndiswrapper
Original-Message-ID: <Pine.LNX.4.44.0311202316500.13351-100000@home.osdl.org>
Date: Fri, 21 Nov 2003 07:28:44 GMT
Message-ID: <fa.kkhpi87.183olgp@ifi.uio.no>

On 20 Nov 2003, H. Peter Anvin wrote:
> By author:    Bill Davidsen <davidsen@tmr.com>
> >
> > I'm curious if the NDIS stuff could be run in ring 1 or 2, being an old
> > MULTICS guy. Not for political reasons, just good tech.
>
> Unfortunately the segmentation and paging were so poorly integrated in
> i386 that rings 1-2 are pretty much totally useless.

That may be the politically sensitive (except to Intel) correct answer,
but in the end I suspect that the _real_ answer is that ring 1/2 are just
fundamentally useless, and it has nothing to do with x86 implementation
semantics or anything else.

Any kind of reasonable performance driver requires direct access to the
buffers it is going to fill in. And not just the actual data contents, but
to the metadata too - the pointers that comprise the skb (or in BSD, mbuf)
lists, etc.

So even if you were to use ring1/2 for the driver, you'd really need to
give write access to a large portion of the data structures that the
"core" kernel networking would use.

Which means that you either put the core kernel in ring1/2 as well (at
which point you don't actually use ring0 for anything interesting at all -
you could put a microkernel there, but hey, there's no real point), or you
map in a _lot_ of ring0 metadata into ring1/2, at which point you lost the
whole point of using a different protection domain.

And quite frankly, if you're willing to actually dynamically map all the
ranges and be careful, why use ring1/2 at all? You might as well use ring3
and make the whole thing be a user-mode wrapper. You'd never perform
really well, but for debugging it is acceptable.

Anyway, whatever way you turn, ring1/2 just don't actually _give_ you
anything. Which is, in the end, the _real_ reason nobody uses them.

(I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent
makes it an even _less_ useful abstraction, but I think it is a mistake to
think that it would be any more useful even if the page tables wasted
precious bits on unnecessary level information).

Multi-ring was a failure. Let it go. The only reason it is making
something of a comeback (Palladium-whatever-it-is-called-today) has no
good technical reasons, and is purely about other things.

		Linus



Newsgroups: fa.linux.kernel
Original-Message-ID: <3FBDC0A4.7080605@zytor.com>
From: "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Announce: ndiswrapper
Date: Fri, 21 Nov 2003 07:38:01 GMT
Message-ID: <fa.eab6117.nk04p5@ifi.uio.no>

Linus Torvalds wrote:
>
> (I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent
> makes it an even _less_ useful abstraction, but I think it is a mistake to
> think that it would be any more useful even if the page tables wasted
> precious bits on unnecessary level information).
 >

Actually, the paging hardware makes 0/1/2 equivalent; some *other*
primitives make 1/2/3 equivalent...

>
> Multi-ring was a failure. Let it go. The only reason it is making
> something of a comeback (Palladium-whatever-it-is-called-today) has no
> good technical reasons, and is purely about other things.
>

No doubt.  However, I wish they would have at least taken the few useful
thing they had in the i286 botch, like the RPL, and made them available
to the paging system.  That way i386 would have had "access this as from
user space" like most architectures have.

	-hpa



Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Announce: ndiswrapper
Original-Message-ID: <Pine.LNX.4.44.0311202349010.13351-100000@home.osdl.org>
Date: Fri, 21 Nov 2003 07:53:05 GMT
Message-ID: <fa.ki1rj0a.1ajqkom@ifi.uio.no>

On Fri, 21 Nov 2003, Nuno Silva wrote:
>
> The good people at Cambridge made a (very nice) VMM that exploits
> ring0/1/3 to let one machine run various kernels independently (the
> kernels need to be ported to the xen arch).

This is what I alluded to a few lines later - saying that if you move the
driver down to ring1, then you should move _everything_ down to ring1 and
just leave a microkernel at ring0.

Now, I'm not big on microkernels, but a pure virtual machine abstraction
is at least not the distateful academic mental masturbation that we saw in
the 80's.

		Linus


Index Home About Blog