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