James Carlson wrote:
> 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.
Ok, however it would be nice to finish the discussion about whether
libast can be used in OS/Net code or not. It's a rather large and
important piece of the project and I'd like to have some kind of
"planning stability". The ksh93-integration project hit too many "last
minute" issues in the past and we're still suffering from that (and this
debate feels very very bitter for me since I thought that the initial
ksh93 ARC case made clear that we introduce libast and USE it where it's
functionality is suiteable).
> > 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.
No, but updating libc is significantly more difficult than a library
which is a little bit further away from the core components.
Additionally we would bloat every single application with these
interfaces - and I think this alone is a very high price for an API
which is not mandatory required by something like POSIX or Unix98
(that's why I am opposed to the idea to merge libnsl/libsocket with
libc).
> > 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.
This depends on the definition of "widely" - as I said I do NOT intend
to switch over half of the OS/Net codebase to use "sfio" or other parts
of libast. Some interesting parts or low-hanging fruits "yes" (for
example the extended pattern matching is VERY usefull) but even that is
likely less than 1% of the applications in OS/Net (another detail is
that once we use libast in those applications we have to test those
applications and are partially responsible for them (e.g. the testing
requirements alone limits the amount of applications we can "invade"
with libast)).
> > > 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.
Umpf... don't you think that this is a little bit far-fetched (if we go
that far I could start bicker about libaio, ZFS, SMF etc. etc.) ? Well,
you can mix&match "sfio" with other types of I/O. Solaris already ships
with such an application which mixes sfio, files, streams, |mmap()|'ed
stuff, CDE and X11 components: "dtksh" (and "sfio" has matured since
those days a lot (Solaris's "dtksh" uses an ancient ksh93d- alpha as
basis (a version which should never be used for production (which didn't
prevent Sun to ship it anyway and then refuse updates... ;-( )))). You
can't mix libast::stdio/sfio with libc::stdio via passing file handles
around (= |FILE *|) - but what is the problem here ? You can't mix
libaio's I/O stuff with libc::stdio either (unless you share the
underlying streams and flush the buffers each time you switch between
APIs).
----
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
