[coyotos-dev] Some comments on Coyotos Microkernel Specification
cap at isg.axmor.com
Sun Dec 4 05:49:04 EST 2005
Jonathan S. Shapiro wrote:
I want to check one assumption first. Is the interface coyotos.cap
supposed to be implemented by all capabilities or by OS-kernel
capabilities only? If it is for kernel capabilities only. Than some
issues go away.
On Mon, 2005-11-07 at 13:04 +0600, Constantine Plotnikov wrote:
>>I have looked into http://www.coyotos.org/docs/ukernel/spec.html
>>and I have noticed few things that might affect API usability
>>from application point of view. (BTW the specification is dated
>>Jan 2005, so some things might have been already fixed).
>>1. typecode is an integer (of some unspecified size, I assume
>> uint32). It is very nice and efficient for kernel objects
>> and for objects that follow some standard. But that approach
>> does not scale well to the custom applications because unique
>> identification of type with numbers will require some central
>> registry (and I do not believe that you would like to host
>> such registry).
>First, type code is actually *alleged* type code. It isn't intended to
>be definitive. Actually, it cannot be -- even a registry cannot ensure
>this, because the application can lie.
I agree with it. However it is irrelevant. Both approaches are identical
in this respect. If application lying about interface, it will just fail
to respond to messages correctly. A client should be ready to have buggy
services and hardware failures on other side anyway. So I see no problem
>It is sufficient if the type code
>Further, type codes are not selected by the application. We use the
>least 32 bits of the SHA-1 hash of the interface name. I have considered
>going to 64 bits, and with the new interface this is more reasonable. We
>may do it.
I think that qualified name is better approach because it can ensure
that there are no collisions between well done interface definitions. In
Java such approach worked quite well. There is usually no conflict
between namespaces of _useful_ libraries. In your approach, if there is
a problem, the problem is forever and it is unfixable and it is not
possible to determine in advance whether there is a conflict. Note:
there is usually no problem with distinguishing garbage object from
Also using qualified name as type identifier gives an immediate hint
where to locate information about service and what service does. Integer
does not provide any of this information. The alleged type can be
printed by the directory listing program for example. The type names are
much better for sorting and
>> Possibly solution is to use typecode defined as
>> canonical UTF-8 string in CORBA-like format like
>> "coyotos.patt:1.0". In such case clashes are less likely if
>> some class/package naming policy like one from Java is used.
>If you think about it, you will conclude that this doesn't help. The
>SHA-1 is just as unique, and the string is not statically boundable.
>Also, the application can still lie.
What do you mean under "the string is not statically boundable"?
The name clash is avoidable if both authors of interface definition
follow some well defined policy. In hash approach, no policy for
conflict avoidance is possible.
>>2. Getting some form of full interface description (including
>> structs, typedefs and referenced interfaces used to define
>> the object) is required for dynamic languages (for example
>> shells). Such information might emitted by IDL compiler.
>> AFAIR it has been planned for EROS.
>Yes. This proves to be MUCH harder than I initially thought, because it
>gets you squarely into versioning issues. In my view, this remains a
>*hard* research problem.
Could please write a message about encoutered problems? I have worked on
several projects that needed to transfer metadata. There are hard
issues. And not all them can be fixed technologically. Some of them are
fixed by introducing a policy or by reducing/expanding amount of metadata.
>> There are at least the
>> following options to achieve this:
>> a. XML. It might be preferable because of readily available
>> libraries for parsing it. Some set of compact tags might
>> be selected.
>> b. IDL. It would require more coding than XML. Also analysis
>> part of IDL compiler (type resolution etc) will have to
>> be reimplementation in every language.
>When the time comes, we will almost certainly use a binary-encoded form
>of the IDL. XML is possible, but problematic, because the @_*_$*$ idiots
>at W3C did not converge on a character encoding scheme.
W3C had a good reason not to fix a encoding if it is what you mean. XML
has been intended for creating documents (like docbook or osdoc). And at
that time there has been almost no editors that worked in UTF-8. And
Unicode support is still a problem in most editors that create plain text.
>>3. Dynamic Invocation Interface and Dynamic Skeleton Interface
>> (CORBA terms). These interfaces should be also defined. Primary
>> users of such interfaces will be dynamic languages (shells,
>> scheme-48, etc.). Note information returned by service described
>> in (2) have to be sufficient for DSI and DDI.
>Can you expand on this? I'm not familiar with either issue.
In short DSI is a library that allows implementing a capability without
usage of IDL compiler at all. DDI is a library that allows invoking a
capability without usage of IDL compiler. Such invocations might be less
efficient than IDL compiler variant.
The following are quotes from CORBA 3.0.3 specification that describe
The Dynamic Invocation Interface (DII) allows dynamic creation and
invocation of requests to objects. A client using this interface to send
a request to an object obtains the same semantics as a client using the
operation stub generated from the type specification.
The Dynamic Skeleton Interface (DSI) allows dynamic handling of object
invocations. That is, rather than being accessed through a skeleton that
is specific to a particular operation, an object’s implementation is
reached through an interface that provides access to the operation name
and parameters in a manner analogous to the client side’s Dynamic
Invocation Interface. Purely static knowledge of those parameters may be
used, or dynamic knowledge (perhaps determined through an Interface
Repository /[const: IDL retrieving operation in case of Coyotos]/) may
also be used, to determine the parameters.
More information about the coyotos-dev