[illumos-Developer] glibc extensions

Garrett D'Amore garrett at damore.org
Tue Oct 19 12:07:55 PDT 2010


We can't be limited to just the APIs that POSIX specifies.  In fact, the
way APIs get promoted to POSIX standards is by their development and use
in operating systems.

There are linker and preprocessor tricks to deal with POSIX standard
conformance issues and namespace collisions.

We can't predict the future, and its not appropriate that we tie our
hands (refusing to innovate) because we don't know what POSIX may or may
not do.

That said, it *does* make sense to carefully examine the APIs being
considered.  Just because an API is in glibc does not, IMO,
automatically mean it makes sense for inclusion in illumos.

The broader issue of extension beyond what *Oracle* has provided is a
topic that is still be discussed within developer council. I'll go out
on a limb (albeit a limb that seems very strong), and say that it
appears that the council is agreed that we can and should allow
extensions to APIs where it makes sense, especially where those APIs are
done in conformance with existing standards (POSIX 2008 for example),
but that we *also* view backwards compatibility with Oracle Solaris as a
desired goal.  (I.e. we would like to avoid the situation where programs
run on Oracle Solaris but not on illumos.)

Sometime soon I hope we will have a formal document explaining this.  At
the moment we're still settling on our procedures within
developer-council, so please be patient.

	- Garrett

On Tue, 2010-10-19 at 19:21 +0100, Owen Shepherd wrote:
> On 19 Oct 2010, at 19:09, Chris Pickett wrote:
> 
> > What will happen if functions with this name become part of the POSIX
> > standard with a slightly incompatible API? Solaris libc has already
> > enough issues with APIs stuck at the prePOSIX and presanity level,
> > unless you turn on some magic switches which blow up 3rd party shared
> > libraries. enable_extended_FILE_stdio and the hidden switch to enable
> > XPG4 conformance in libc are prime examples for problems caused by
> > such improper design.
> > 
> > Chris
> 
> 
> What names would you suggest to avoid conflicts then?
> 
> -- Owen
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer





More information about the Developer mailing list