Re: [9fans] RPC-esque system calls?

["Lluís Batlle" <viriketo@gmail.com>]

In some years, there will be huge root DTD servers as there are now
root DNS servers ;)

2007/7/24, Uriel <uriel99@gmail.com>:
> > I'd encapsulate messages into SOAP (XML) envelopes.
>
> We are in April already? Wow, how fast the years go by, must be the
> speed of progress in the software industry.
>
> uriel
>
>
> On 7/24/07, Francesco Frigo <frigofra__NOSPAM__@tin.it> wrote:
> > Hi,
> >
> > I'm just going to talk about some random ideas I have.
> > I haven't implemented anything of this yet, and I guess some might be a
> > bit impractical to.
> > However, I'd like to hear your comments about them.
> >
> > What I'm going to talk about is the system call interface.
> > Nowadays, in most general-purpose operating systems the common approach
> > seems to be as follows:
> > a user library (like the C library) with some wrapper functions that take
> > arguments in a high level programming language.
> > Arguments are packed into CPU registers and an interrupt is called, that
> > is responsible of switching from user mode to kernel mode.
> > A kernel mode handler carries out the demultiplexing of the system call
> > (according to a value in a register which can be thought of as a system
> > call identifier) and calls the appropriate operating system functions in
> > order to carry out the task.
> > The way back to user mode is the reverse.
> >
> > Now, this is very nice, because it's fast, reliable and not too error
> > prone.
> > However I'm thinking of another architecture, which is nothing new maybe,
> > but it could help developing a distributed system.
> >
> > Let aside any security measures here.
> > Let's just assume we're working in a safe environment, like a laboratory
> > cluster, which has no outside access.
> > Just for the sake of reducing complexity.
> >
> > The mechanism I have in mind is a sort of RPC.
> > The key concept is that it is the only mechanism available, thus enforcing
> > its adoption.
> > I hear you say: "hey, but what if we're in local? Isn't it a bottle neck?"
> > Yes, it may be.
> > But let's not worry about it yet.
> >
> > First of all, we need a means to identify resources, both local ones and
> > remote ones.
> > The (ssh-like) URI idea seems to be good enough for it.
> >
> > cat anne@computer_one:/dev/microphone > anne@computer_two:/dev/speakers
> >
> > Ok... it's very naive, I admit; but it's just an example.
> >
> > What else do we need?
> > 1) A common interface to devices and files (like Plan 9)
> > 2) A common protocol for accessing resources
> > 3) An operating system to implement those
> >
> > The common interface is rather simple, it's been around for years.
> > It's the simple: open, close, read, write, ...
> >
> > The common protocol... well Plan 9 uses 9P, which is very nice, but I have
> > a different approach.
> >
> > I'd encapsulate messages into SOAP (XML) envelopes.
> >
> > This has one big advantage and one big disadvantage.
> > Advantage: it has no endianness problems, because it's just text in some
> > encoding.
> > Disadvantage: it is horrendously inefficient.
> >
> > However it has also got other nice aspects:
> > - it's easy to create new messages: the whole infrastructure is there, you
> > just have to generate some XML.
> > - [I believe] it is a simple concept to understand
> > - [I believe] it is simple to debug (messages are easily interpretable)
> >
> > How does it work?
> >
> > Well, the high-level language part and the library are the same... so a
> > user can just call, say: fgets(buffer,BUFFER_SIZE,stream);
> > The library packs it into an XML message with a SOAP envelope and calls an
> > interrupt (just like it happens now).
> > However the bottle neck is that instead of passing a few values in a few
> > registers, you have a string to copy (the XML message).
> > But well, we don't care for this now, do we?
> >
> > Then, the operating system analyzes the message, and it decided whether
> > it's a local or a remote operation.
> > If it's a local one, it just carries it out and it sends an XML message
> > back to the user process, and the C library will just decode it and return
> > a value to the user in the standard way.
> > Basically... the user doesn't know what's going on under the C API, it's
> > transparent (as much as possible).
> >
> > If it isn't a local operation, the kernel acts as a proxy and forwards the
> > request to the target host, which in turn will realize it's a proxy
> > operation and it will return values back to the caller.
> >
> > What's good it for, despite it being reasonably slow?
> > Well... you can access resources transparently in EVERY system, just like
> > you would access normal resources.
> >
> > The key concept is:
> > what you can do locally you can also do remotely.
> >
> > ...by virtue of making it the *single* way to access the kernel.
> > So you can't say: "this is going to be implemented for the local interface
> > only... we'll take care of the remote one afterwards", no way.
> >
> >
> > My last warnings:
> > I'm not saying this is THE future, or THE BEST approach.
> > I admit it's not a new idea... my main contribution is the XML/SOAP
> > approach.
> > I'm just saying: "let's see what folks think about it." :-) It
> > has many drawbacks, first of all its inefficiency. But one has to see the
> > trade-off... yes, it is inefficient, but it gives you a good advantage.
> >
> > That being said, please don't flame.
> >
> > Bye bye,
> >   Franky
> >
>