Hi, On Fri, May 23, 2008 at 09:04:49PM +0100, Flávio Cruz wrote:
> Here's what I pretend to do during the summer session for GSOC: A little side node: You are regularily using "pretend" in a manner that doesn't quite fit the context in English, and in fact is quite amusing :-) > Will involve the creation of an API that can generate new RPC calls as > MIG does but using Lisp macros. I don't think it's a good idea to define the interfaces in a completely new way. This will create redundancy, with all the associated disadvantages rdeundancy cretes. We better avoid the disadvntages of reddundancy. I don't want to see the disadvantgaes of rdundancy creep in. It would be quite cumbersome to deal with the disavantages of redundany. The diadvan... well, I guess you get the point ;-) Rather, reuse the existing .defs, only creating Lisp interfaces from them instead of C interfaces. BTW, what about the option of invoking the MiG-generated C stubs rather than creating native stubs in Lisp; have you considered that? I'm not saying that I think it's a better option; but I'd like to see a discussion of advantages and disadvantages of redun^W^W^W^W^W err I mean the advantages and disadvantages of both approaches... (And in fact also for other approaches like binding to existing libraries -- you now say that you want to do it this way as if was the most normal thing in the world, but never explain your motivation for that change... Don't leave us groping in the dark! :-) ) > This interface should be micro-kernel agnostic. Of course the inner > layer will be for GNU Mach, but it should be easy to port it to future > kernels, if it will be the case ;) That's a laudable goal, but unfortunately rather a hopeless one :-) The way RPC interfaces look, depends on the features of the microkernel in many ways. A different microkernel requires different interface definitions. More generally speaking, operating system design is hard -- but I guess you already knew that much ;-) -antrik-
