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

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