[lkml]   [2000]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ANNOUNCE: Linux Kernel ORB: kORBit
> > >
> Arrgh. s/plan-9/plan9/. My apologies.

Cool, thanks, will read. :)

> IDGI. What 9P gives is an RPC mechanism that uses normal (as in "named streams
> of characters") representation on the client side and very light-weight
> library on the server side. It looks like you are trying to do a mechanism
> that would export arbitrary _internal_ kernel APIs. I really don't see
> what you would want it for.

Which is exactly why it doesn't work well for many applications. The
problem is this: how do you get from a byte stream to a structured data
stream? There are many answers:

1. Keep your data structures so simple, that it's obvious. Not a good
choice. :)
2. Defined interfaces to the bytestream for every interface that you
3. Define a standard for inflating/deflating "things" into
bytestreams. Oh wait, that's what corba does. :)

The point of the matter is that CORBA gives you a nice, clean, well
supported method of not having to write marshalling/demarshalling code
every time you want to use an interface. Not only that, it lets you
define "fast paths" for special cases (ie, with user level corba, if you
are communicating between two objects in the same processes, you can do
direct calls and do no marshalling). These fast paths do not interfere
with the generality of the system at all.

The 9P way of doing things is not fundementally new, they just applied the
idea that "everything is a file" more broadly. What annoys me is that it
is not immediately obvious how to "demarshall" the data that comes out of
/dev/mouse for example. Combine that with the problem that /dev/mouse
might change format in the future (okay stupid example, but you get the
idea) to use floating point coordinates, and things certainly get hairy.

Why reinvent the wheel countless times?


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.073 / U:3.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site