lkml.org 
[lkml]   [2000]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CORBA vs 9P


On Wed, 13 Dec 2000, Chris Lattner wrote:

> > > Okay, so there are _stubs_ for these platforms. How many languages are
> > > there bindings for?
> > Grr... Let's define the terms, OK? What is available: kernel code that
> > represents the client side of RPC as a filesystem. Userland clients do
> > not know (or care) about the mechanisms involved.
>
> But they DO CARE about the format of the data.

And how would CORBA help here? Because format changes are usually coming
from the _contents_ changes. And if you don't care about the contents -
why the hell do you retrieve the object int the first place?

> > And files with structure are things of dreadful past. BTDT.
> > You really need to... work with an OS that would have and enforce
> > "structured files" <spit> to appreciate the beauty of ASCII streams.
>
> Ahhh, so ASCII streams are a wonderful thing. Are you an XML fan? :)

No, thanks.

> > However, that's a different story. What I _really_ don't understand
> > is the need to export anything structured from kernel to userland.
>
> Okay, how about a few examples. How about /proc/meminfo? How about the
> "stat" structure? How about /proc/stat? You seem to be indicating that
> ASCII files are fine for general exportation of kernel information. The

Yes, _if_ you take care to think what you are exporting. /proc/meminfo is
a shi..ning example of _not_ doing that over many years.

> /proc filesystem begs to differ. One specific example is the
> /proc/meminfo file. Why is it that one field is 0 now? Ouch we can't
> change the format of the file because we'll break some program. Crap, you
> want to add a field, well, tough luck.

Oh, cool. So CORBA would magically change the definition of the structure in
your (C/Modula-3/APL/COBOL) programs. How? And what would happen with the
code that used to access the field in question?

> The struct stat example is one _trivial_ example of "the need to export
> anything structured from kernel to userland".

It's a trivial example of "why you need to think before deciding what to
export".

> > IOW, I would really like to see a description of use of your
> > mechanism. If it's something along the lines of "let's take a network
> > card driver, implement it in userland and preserve the current API" -
> > see the comment about layering violations. You've taken an internal
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > API and exposed it to userland in all gory details. See also your own
> > comment about internal APIs being not convenient for such operations.
>
> I'm not trying to dictate interfaces. I'm not trying to tell people what
> to use this stuff for. I'm arguing that it's useful and that you can do
> very interesting things with it.

And when interface changes, you do what, exactly?

> > If it's something else - I wonder what kind of objects you are talking
> > about and why opaque stuff (== file descriptors) would not be sufficient.
>
> Opaque stuff is fine. I have no problem with file descriptors. They
> effectively solve the exact same class of problems that CORBA does, except
> that they add significant _API BLOAT_ because every little "method" that
> implements them gets a syscall.

Huh? Could you elaborate, please?

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

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