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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to