OS-Design:Corba, Bonobo and XPCOM (Components)

[smurf975]

Hi,

I'm doing a microkernel OS with servers on top of these. Kinda like BeOS.

Now I want to make things as easy as possible for application developers and OS developers as possible.

The big buzword on windows for stopping the DLL Hell was active x and DCOM.

Now to get to the point: I want those server running on to the kernel to be like blackboxes and languange independent. So if we update a server or you want to do low level graphics programming in this OS with Basic (with extensions) it shouldn't matter.

I think the solution for this is using component based software like this threads title.

Do you think its feasible?

Examples of my servers that I want to do component based: Networking, Graphics, Devices, Input.

However the catch to this is:
1. The OS must have low latency. ITs an multimedia OS.
2. Small memory and CPU footprint. The OS should be able to run on 32MB of RAM.
3. Must improve the development of applications making use of it.

Thanks in advance.

[Pype.Clicker]

i'm not very comfortable with those middleware technologies, but - afaik - CORBA is mainly aimed at over-network distributed applications ... is this really a good technology choice for such a core level ? i doubt about it ...

i don't mean component programming or interface description language is bad at kernel level -- clicker attemps to use both -- i just doubt you really need a 16 bytes Unique Identifier for your components.

And the query-interface scheme never convinced me ...

Now surely fans on COM will have different opinion, but mine is those thechnologies (such as imho XML and JAVA) are not well-suited for kernel programming ...

[smurf975]

But they will never touch the kernel. They will only touch the servers. Look at this picture for an idea: http://www.xs4all.nl/~smurfy/storage/kernel_servers.gif

Now those servers are kinda of like middleware and object oriented. I will do them in C++. A problem I just thought is however that each server must be able to be ran as a kernel module. Which is set at boot time.

I know CORBA is a bit heavy weight. I read that the developers from GNOME/Bonobo forked CORBA but left a whole bunch out. But its still heavy.

I havn't read to much about XPCOM(mozilla) http://www-106.ibm.com/developerworks/webservices/library/co-xpcom.html.

Apple is also using COM in its new OSX. I can't find the link now but I read that its using ms-com for driver development. (I read a driver developers diary and he really liked it).

So I didn't intend to just take corba and implement it in my OS. Only the pure basics.

I want to know if its worth the effort or just stick to normal libraries and dll's. I think they will be faster.

thanks

[_mark]

I would just have some well defined interface in the form of structs and function prototypes. In a kernel this is all you need. IMHO COM and CORBA are way overrated, but that is a whole different topic.

_mark()

[df]

corba is heavy.
a slimmed down version is iirc, DCE-RPC. it was the original base iirc for some of the COM ideas (idl, etc), as well as CORBA.

worth looking into...

[smurf975]

DCE-RPC seems to be designed for distrubuted computing. Or networks

Now I have nothing agianst it but networking is a second objective of my OS. Not primary. Also it is not an object oriented framework. But thanks for the information anyway as now I know a little more of the history of components. ;D

With the information I got from all of you I will think some more about it. Its not a show stopper not having a IDL. And if I have more questions and more specific questions. I will ask agian.

Thanks

[_mark]

If you are using C++, and you are still thinking of persueing interfaces in the kernel, I would suggest you read "Inside COM" by Dale Rogerson. You can basically roll your own COM like architecture without all the COM fluff. You have no reason to use GUIDS or a registery, and the book starts off by showing you exactly how to do that.

_mark()

[df]

smoe of the concepts behind com, i really like. but it all goes back to dce-rpc

com has its pitfalls and shortcommings too but also its good points

[smurf975]

If you are using C++, and you are still thinking of persueing interfaces in the kernel, I would suggest you read "Inside COM" by Dale Rogerson.

>> I never wanted to do it in the kernel. I'm doing a microkernel and I want to keep it this way.

You can basically roll your own COM like architecture without all the COM fluff. You have no reason to use GUIDS or a registery, and the book starts off by showing you exactly how to do that.

>> Yes this what I was thinking of however maybe basing it at a known package and dumbing the stuff I don't need. However I'm not sure if its needed. I mean maybe developers are happy with straight libaries like on Linux. I don't know.

Smurf

_mark()

[Pype.Clicker]

I think it'll be hard to tell whether component will be good or bad prior to know *where* exactly they will be used, but if it's going to be the main communication mean between clients (regular programs) and system servers, then you'll have to put the support for components in the microkernel as the microkernel's role is to interconnect other components ...

[Crazed123]

I know this is necromancy, but it was in Quicklinkz and this is a valid components programming question.

I'm integrating the notion of components into my system at a low level. Each process or library gets its own address space, whether or not it has any associated threads. From there it can export interfaces. I'm pretty much well solving most issues with this, but the question remains: what should be the internal kernel representation of an interface? Since this stuff is handled at a kernel level some mechanism is needed to keep track of the interfaces in a context (process or library) and know what's actually IN them. I figure that some kind of table or something should probably be used, but what information about an interface (other than the obvious stuff like its identifiers) should be stored in that table?

[Legend]

DCE-RPC seems to be designed for distrubuted computing. Or networks

That is not really a problem as long you are allowed to provide a faster way to pass a function call along then through an IP-Stack.

If I communicate to another process on the same machine or to another process on another machine, where is the conceptual difference for the process that wants to communicate?

The tools that are provided are different but could be transparently adapted, too. Shared memory over a network would probably be awfully slow, but it should be doable (not that I would want to).

[Pype.Clicker]

what should be the internal kernel representation of an interface? (other than the obvious stuff like its identifiers) should be stored in that table?

Well, i'd say that you should at least provide the list of method the interface supports, but actually, it mainly depends on how strong the 'identifier' is.
The system should at least make sure that the requested interface is the same as the one provided (by the mean of hashes, or UUID or whatever is guaranteed to be unique and easy to compare).

What else is stored will probably depend on how reflexive you wnat your interfaces to be. E.g. if you want that a component can dynamically discover what interfaces a component offer, and how it can be queried, etc. you probably need more such as the list of methods and the argument they accept. Beyond scripting, it can be useful if you have to dynamically create stubs/proxies for a given interface in a generic way.

Note, however, that a remote service could be responsible from giving out the description of the interface given its UUID. This doesn't necessarily need to be in the kernel itself.

[JoeKayzA]

I plan to use interface identifiers as the only means how the kernel (or, at least, the core parts of the kernel) sees interfaces. IMO, it doesn't need to know about specific methods inside an interface - it just provides a message port to the server, which represents the interface then. Method calls are issued through messages then, and the server should check whether specific methods are supported or not - but IMO the client should already know about all the methods when it knows about the interface identifier.

I've not yet made up my mind about how to do those interface identifiers, however. (Somehow I'm not comfortable with the GUID-thing either)

Things like reflection, interface query and stuff will probably all be handled at the server side then (agreeing with Pype here). Every object will have to support a basic 'object'-interface, which offers methods for all this stuff, as well as retrieving additional interfaces from the object.

cheers Joe

[Pype.Clicker]

If i may add, i'd say that component frameworks designers should make sure that their design is programming-friendly. E.g. the server program shouldn't have to write anything down that enumerates interfaces and it certainly shouldn't be requested to give documentation/methods/arguments about the interfaces. Instead, i'd advocate for a repository (or an component-support server) to offer that information.

When you create a component, you tell what interfaces it supports by using your OO language facilities. Nothing more should be required. E.g. if a UUID is to be used, then it should be part of the interface definition you #included, not part of your program. That also means that the encoding of supported interfaces for a given object is somehow part of your ABI, so that any other tool can inspect and check for a particular interface.

In otherwords

Code: Select all

MyObject::IIUnknown(IUID_t interface_id) {
   if (interface_id == HELLO_WORLD_IUID) return hello_interface;
   if (interface_id == SOME_OTHER_IUID) return other_interface;
   throw new UnsupportedInterface(interface_id);
}

is something you shouldn't ever have to write in a properly designed component framework ...