It occurs to me that this whole debate could largely be shelved by
making libast's interfaces "project private" (or whatever is that
commitment level now), basically undocumented, and let other projects
that want to start using it start up a case with a contract to do so.
Then each case-by-case can get reviewed by PSARC in order to get a
contract to use the libast interfaces.
Once upon a time, this might have called for something that used to be
called an "inception review" at ARC, which would have served to present
the larger scope of libast to PSARC.
If we went this route, then the whole debate about whether or not
libast's interfaces should be public could be done at a later time, when
a little more experience with it is available by developers besides just
Roland.
Just a thought.
-- Garrett
Roland Mainz wrote:
> 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
>
>
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
