James Carlson wrote:
> John Plocher writes:
> > IMHO, the conversations here should be less like "I don't like that
> > idea, and here is why it is bad" and more like "Interesting - how
> > can we together help you make this a successful part of our OS?".
>
> The idea I don't like is having a _separate_ libast that provides an
> enhanced stdio experience.
Grumpf... "sfio" is different from "stdio". It can act as stdio
replacement via an additional set of wrappers but "sfio" is still
different. It'd an I/O library (if we want to bicker about that then
lets attack things like libsendmail.so, too...). The stdio wrappers are
just an additinal features and nothing I'd like to spread any further
than neccesary (as the wrappers need some overhead which can be avoided
by using "sfio" directly).
And more important: libast does not only contain "sfio" - there is MUCH
more in this library and most of this stuff could be usefull in the one
or other form (at this point I wish we could abort throwing bricks at
the stdio wrappers in libast).
> How many of those should we have? Is two stdios enough, or should we
> have seven? Why not build all our utilities atop NSPR?
NSPR is a different beast. Yes, part of libast is a portability/platform
abstraction layer like NSPR but that's not all (and in the case of
Solaris most of these parts are direct pass-through without even
touching any code in libast (it's handled directly at the source level
and therefore avoiding any overhead)).
> 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 ? 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...)) ? 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.
> 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.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
