Hi list, Since I works on the IDL/ORB design I want list to have some discuss on it. I'm writing the white paper about this subject and I want present some basics of this design. Well, firstly I take a look to CORBA/ORB (specifications and some implementations) i.e. I don't making something new (it's not necessary), second - all of my ideas was taken from several projects - L4 Dice(http://www.inf.tu-dresden.de/index.php?node_id=1539&ln=en), Qedo (http://qedo.berlios.de/project.php4?lang=eng) and some other (this two ones has more influence to my design). In first of all I want to list features that should be supported by design: - flexible - layered (IDL should works on different layers) - simplicity - extensible (since we're want to support industrial standards it's a good time to think about) Advantages. Flexibility. It's very possible that we will change some identification rules (DAC/MAC/capability etc). This will affect low level part of ORB/IDL. I think that we need in some abstract interface for it that might be changed with simple relinking with different low level ORB/IDL library. Layered design. Protocol headers may contain several stuff i.e. one data for one layer, other data for other layer and so on. If we will has a possibility to get IDL stuff works anywhere we will simply be able to compound server parts in any ways (for example we will able to split filesystem with block device driver in a one single service, or contrary divide top abstract device driver from low level device driver in different services). Simplicity. IDL should be simple as it possible, it will allow us to assemble new interface and new subsystems in a short time terms. Extensible. Many industrial standards require many features as QoS, transparent data flow etc ... Disadvantages. Additional libraries will be added. New abstract structures will waste some memory. Build process will became more sophisticated and complex. IDL syntax knowledge will be required for development.
Going on, I want to describe the basics. There are several major parts of IDL/ORB will be exist: - IDL (specialized DSL conforming to CORBA) - IDL compiler (primary for C only) - libraries one for client, other for server (typical client applications doesn't required server stuff) On the low level of ORB/IDL new abstraction will be added, it's called 'ticket', well what is it? Ticket is a request identification that contain permissions and client identification stuff. For example, currently (with nowadays design) it will be a structure with uid, gid(primary group), pid of the client, but on future it may contain labels, name space id etc. It also might be a binding for capability assigned for the client, or something else. This abstract structure will be operated by library with some abstract interface that will used in the IDL generated code. I attach the abstract diagram of the design in this email. On this diagram you will see a message - message is IPC object, but it will always contain ticket and IDL data. Library can use low level IPC/IPCbox features to get the ticket (ipc_message_info currently), but ticket may be extended with optional values (for example some session identifications). IDL data processed by the IDL generated code (using sbuf in our case). Both the client and the server will has the same defined structures. So, data flow will looks like: - server ORB lib get message, take ticket and call the IDL code - IDL code take sbuf from library, parse protocol headers, call required procedure with ticket and parsed data - if you need additional protocol parsing your calls may call IDL code again for top layer protocol parser - in finite stage procedure call IDL code to reply/forward the message Any comments ? is there questions ? PS I'm not sure that I explained basics of this design so good as it should be. -- Alfeiks Kaänoken, Team Lead of the Jari OS R&D Team. http://jarios.org Free open-source microkernel-based multiservice RTOS
<<attachment: fig1_abstract.png>>
_______________________________________________ Jarios-dev mailing list [email protected] http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev
