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