On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> /me trims down CC list...
>
> > Local? Funny. It lives atop of TCP or IL quite fine. What's
> > even funnier, I can use it to export /proc from CPU server to workstation
> > and use _that_ for remote debugging. Ditto for window system. Ditto for
> > DNS. Ditto for plumber. No, not on Linux...
>
> No not on linux. No definately not on Windows, no not on the BSD's
> either. Oops, wasn't interoperability an important part of the Linux
> kernel design? Didn't we want to use and follow and define _real_
> standards?
Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that
it exists for other *BSD too - never checked that.
> > What you do is mapping your RPC to hierarchical namespace. After
> > that... What extensibility do you need? You can use every utility written
> > for core UNIX API (open()/read()/write()/close()) as a client. No need
> > to reinvent the wheel...
>
> Heh, that's interesting. _getting_ the data isn't hard in 9P, actually
> using it or displaying it in a meaningful way commonly requires something
> more than cat. :)
Same for any other RPC mechanism.
> The overriding problem with a simplistic 9P port is that linux kernel
> functionality is not very well modularized. In fact, this prevents
> wonderful CORBA integration as well: An agressive filesystem (for
> example) often likes to touch the buffer cache or even the VM layer
> (*cough*) directly. Some don't use the prescribed interfaces, because
> nothing enforces it. 9P works wonderfully for Plan9 because they had the
> luxery of redefining/rewriting the whole OS, and the whole interaction
> with user space processes. We, unfortunately, don't have that
> possibility. :)
Notice that they _don't_ export random internal APIs to userland.
> Please don't get me wrong. I'm not opposed to other ideas, and 9P may in
> fact turn out to be a very nice protocol that would be able to support
> much kORBit level functionality). I do maintain that by writing a custom
> user->kernel marshalling library, you could obtain better peformance than
> 9P though, because you could take advantage of lots of machine specific
> optimizations. Hell you could even pass things in register if you'd have
> <= 4 args. :)
You mentioned OOP, didn't you? Encapsulation is a good thing and what you
are talking about is "layering violations made Real Easy(tm)".
I simply don't see why _that_ is a good goal.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 15 2000 - 21:00:28 EST