[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Jonathan S. Shapiro]

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

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

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

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

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

> 4. reduce() operation misses some important counterpart that allows
>    to discover meaning of the bits. The problem is meaning of bits
>    might depend on specific interface implementation and is generally
>    orthogonal to interface of the object. For example file system might
>    provide file object with bits meaning "read, write", but some
>    application might provide file object proxy with bits meaning
>    "write,read-on-workdays,read-on-weekend".

Reduce isn't that general. It's the *kernel* operation, and it operates
only on the kernel view of the capabilities. Given this, a
getReduceDescriptor() isn't necessary.

> Also the section "1.1 Microkernel Abstractions" contains strange loop
> in definition of schedules. Process must name a schedule capability
> to run, but as I guess it has to run to name a schedule capability.

The fabricator must install a schedule capability into the process
schedule slot. I concur that the description should be cleaner.

shap