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.
If it is Project Private to the ksh93 project no it can not, at least
not until a case to raise its taxonomy to Consolidation Private,
Uncommitted or Committed is approved.
If it is Consolidation Private then that taxonomy rules allow it but
wither or not it is the correct thing to do and should be allowed by the
definition is a discussion to be had with the particular project that
wants to use it.
No, but updating libc is significantly more difficult than a library
which is a little bit further away from the core components.
Actually I think it is the other way around. Putting stuff in libc is
easier because then libc can often use it and you don't need to worry
about dependency loops. Let me give you an example, I want to have
crypt_gensalt(3c) [ which is in libc ] lookup a user_attr(4) key/value
pair, that means a libc function needs to use functions in libsecdb -
this gets messy really quickly!
--
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
