RPC-esque system calls? - Plan9

This is a discussion on RPC-esque system calls? - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: RPC-esque system calls?

  1. RPC-esque system calls?

    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

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

    > 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

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

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


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

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

    2007/7/24, 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 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
    > >

    >


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

    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)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

  6. Re: RPC-esque system calls?

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

    Bye bye,
    Franky

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

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


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

    On 7/24/07, Francesco Frigo 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

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

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


+ Reply to Thread