From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Tue, 24 Jul 2007 11:03:22 +0000 From: Francesco Frigo Message-ID: <46a5d276$0$36452$4fafbaef@reader5.news.tin.it> Content-Type: text/plain; charset=UTF-8 Subject: [9fans] RPC-esque system calls? Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 95e96ab8-ead2-11e9-9d60-3106f5b1d025 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 enforcin= g its adoption. I hear you say: "hey, but what if we're in local? Isn't it a bottle neck?= " Yes, it may be.=20 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 hav= e 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, yo= u 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 a= n 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 retur= n 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 th= e 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 interfac= e 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