[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Constantine Plotnikov]

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 
here.


>It is sufficient if the type code
>discourages collisions.
>
>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 
garbage object.

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 functionality:


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.

Constantine