Joerg Schilling wrote:
> "Garrett D'Amore" <gdamore at sun.com> wrote:
>> No, not really.  If you want to create a new portability layer, then 
>> please propose a new case.  This case is about the rmt and star 
>> application programs, and the supporting librmt.
> 
> This is not a new portability layer. It is in use since more than 15 years.

Repeat after me:  "It is a new portability layer for OpenSolaris".
It is also NOT THIS CASE.

If/When you pursue such a case, consider the question of why you
feel that OpenSolaris needs a portability layer for things being delivered
by OpenSolaris?

OpenSolaris shouldn't become a dumping ground for random subsystems - ast
or schillix; rather we should consider what is best for OpenSolaris and
choose architectural strategies and direction by intent and not by stealth.

Part of this is asking who the intended consumer is of such a portability
layer?

The Schillix tools?
    Sounds like a compile time/source tree issue, not a end-user
    deliverable.

Tools in OpenSolaris that are retrofitted to use the portability layer?
    Why would we do that instead of using native OpenSolaris
    interfaces?  In other words, add the various things to the existing
    files in /usr/include so that they work better rather than layering
    on another abstraction layer.

Existing end user applications?
    Who else uses these interfaces today?  If none, then where is the need?

Potential future end user applications?
    Might be an interesting use case....

Something else?


   -John


Reply via email to