[lkml]   [2000]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit

> > 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.

Okay, so there are _stubs_ for these platforms. How many languages are
there bindings for? What about Win32 (gross I know, but at least for now,
it is important)? What about OS/2 what about Amiga and palm? CORBA is
very popular for certain things... even inferno isn't nearly as big...

> > 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.

Of course. Which is why CORBA is about putting STRUCTURE in that stream
of random bytes coming over the wire. Why should I have to rewrite my
marshalling and demarshalling code every time I want to write a
server. read and write are fine. But sometimes I want a
structure. Sometimes, my structures aren't laid out like C struct's
either. What then? What if I want to send an "object" to you?

> > 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.

And neither do we. Beautiful isn't it? :)

> > 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.

I completely fail to see how I'm breaking encapsulation or making layering
violations easy. Why I'm talking about is the fact that CORBA doesn't
care how you ship bytes around: it's a higher level protocol that cares
about shipping "things" around. Bytes are old school, "stuff" is the wave
of the future. ;) heh.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.126 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site