From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45219fb00707240646o34d44ff2i1e9b11f208d1570c@mail.gmail.com> Date: Tue, 24 Jul 2007 15:46:59 +0200 From: "=?ISO-8859-1?Q?Llu=EDs_Batlle?=" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] RPC-esque system calls? In-Reply-To: <5d375e920707240624x1da18a4ei41c14e7ab688724b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46a5d276$0$36452$4fafbaef@reader5.news.tin.it> <5d375e920707240624x1da18a4ei41c14e7ab688724b@mail.gmail.com> Topicbox-Message-UUID: 965a4af8-ead2-11e9-9d60-3106f5b1d025 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 > > >