Roland Mainz writes:
> > I have no problem seeing that libast has good stuff in it. I'm not
> > trying to debate that question at all. Instead, since it's good, I'd
> > like to see how it gets integrated into Solaris itself, rather than
> > just bolted on the side.
>
> What would be your suggestion ? Move all the code into libc ?
Some, possibly. I'm not really interested in designing it right here.
> What if we
> want to _change_ the code to meet new requirements (for example at least
> I'd like to make most of the libast interfaces reentrant and threadsafe
> ("sfio" is already threadsafe but there are other parts which need the
> whips...)) ?
The code in libc (and other existing Solaris components) is not
immutable.
> What if some part of libast makes it into a future POSIX
> standard but in a slightly modified form ? In these cases we would bloat
> libc and curse the day when we originally moved those pieces into libc.
Yes, potential evolution in the interfaces is one reason to avoid
fixing it in stone just yet. It's also one good reason to avoid using
it widely until it has stabilized sufficiently that this isn't a
concern.
> > These sorts of forks are _not_ zero-cost experiments that we can just
> > foist off on the product. Consider what happens when different
> > layered libraries start targeting separate underlying and different
> > stdio enhancements -- how does an application deal with mutually
> > incompatible architectural directions?
>
> At least for libast it's easy since symbols and structs are isolated (if
> you look at the mapfile-spec file for libast you'll see that many of the
> symbols start with |_ast_*()| unless it is obvious that no other
> namespace collisions can occur and at source-level there is some
> #define/typedef hackery to make sure that the correct versions are used.
That's not the sort of problem I'm referring to. If you can't open an
I/O stream from one library and use the same object with another
library, then the two aren't compatible and are difficult to use in a
single application.
Forcing users to choose between sfio and other possible alternatives
means that some will likely make arbitrary choices. That's the "fork"
I'm referring to above.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
