[9fans] RPC-esque system calls?

[9fans] RPC-esque system calls?

[Francesco Frigo]

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

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

[erik quanstrom]

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

plan 9 can already do this

	import computer_one /dev /n/dev1
	import computer_two /dev /n/dev2
	cat /n/dev1/microphone>/n/dev2/speakers
	
> 
> What else do we need?
> 1) A common interface to devices and files (like Plan 9)

it seems you already know 9p can do this.

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

i see no advantage as 9p does not have an endian problem.

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

9p has these properties.

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

this sounds like a vague discription of a process' mount table.

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

perhaps some of the papers  here (http://plan9.bell-labs.com/sys/doc/)
would be helpful.  i'd start with _the organization of networks in plan 9_.

- erik

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

[Uriel]

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

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

[Lluís Batlle]

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

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

[tlaronde]

On Tue, Jul 24, 2007 at 03:24:57PM +0200, Uriel wrote:
> >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.

That's the problem with jokes---I mean XML.

tar_and_feather was too long. Vaseline was considered politically
incorrect. So they ended with: SOAP, which, unfortunately, is so weak
that it has been taken seriously.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

[Francesco Frigo]

Sorry guys, I apologize.
I posted it to the wrong newsgroup.

Bye bye,
  Franky

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

[C H Forsyth]

> I posted it to the wrong newsgroup.

no, it was a good group to choose.
if you ignore the jokey comments, read  erik quanstrom's note carefully,
and follow up his references, you'll see that plan 9 shows how to do
all that you suggest (or nearly all), simply (much less code and mechanism),
and in fact better in the abstract.

better?  take this example, for instance

> > The (ssh-like) URI idea seems to be good enough for it.
> >
> > cat anne@computer_one:/dev/microphone > anne@computer_two:/dev/speakers

See ``The Hideous Name'' (http://netlib.bell-labs.com/cm/cs/doc/85/1-05.ps.gz) for instance,
and note that it dates from 1985 -- 22 years ago!

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

[Joel C. Salomon]

On 7/24/07, Francesco Frigo <frigofra__NOSPAM__@tin.it> wrote:
> I posted it to the wrong newsgroup.

Just curious:  Where did you intend to post this?  I'd like to follow
how the conversation goes outside 9fans.

--Joel

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

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 99 bytes --]

i assumed he meant that he hadn't got a warm reception here
so it was obviously the wrong group.

[-- Attachment #2: Type: message/rfc822, Size: 3658 bytes --]

From: "Joel C. Salomon" <joelcsalomon@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: RPC-esque system calls?
Date: Wed, 25 Jul 2007 09:47:04 -0400
Message-ID: <7871fcf50707250647l15dfd279sa7e80fc311bc1658@mail.gmail.com>

On 7/24/07, Francesco Frigo <frigofra__NOSPAM__@tin.it> wrote:
> I posted it to the wrong newsgroup.

Just curious:  Where did you intend to post this?  I'd like to follow
how the conversation goes outside 9fans.

--Joel