Roland Mainz wrote:
> James Carlson wrote:
>
>> Richard Lowe writes:
>>
> [snip]
>
>> I was referring to moving strings to constant sections where possible
>> and perhaps investigating command performance.
>>
>> I agree that spreading ksh's private stdio replacement around requires
>> a much more substantial conversation, and I'm mostly opposed to it.
>>
>
> Could you please explain why you are opposed to it (note that I was
> thinking about using "sfio" (and other things), not the libast stdio
> wrappers (which are (right now) only needed for things like making an
> application/tool/etc. work as ksh93 plugin (or allow easy plug&&play
> porting of applications overr to "sfio")) ?
>
>
>> (If it's generally useful, then it belongs in libc, not as an outboard
>> motor.)
>>
>
> Why (again I am thinking more about the stack/list/queue/tree/etc.
> infratructure and sfio (these are the major items of libast)) ?
>
I believe that if these functions are of such core utility, that they
should be added to libc itself. IMO, as an outsider, I've not been too
happy with the way some of the extra "bolt-ons" (c.f. libadm.so) have
been handled, as undocumented (or poorly documented) functions, which
require extra linker flags to get at, and which are often not available
outside of ON.
Much better, IMO, to fully promote generally useful shared routines into
libc.
Plus, that makes it possible to use these functions inside libc
implementation as well, perhaps gaining even further benefit.
Also, even though it is quite small, each library adds additional
run-time overhead due to an extra file descriptor, open, and mmap being
required. There may be other overhead associated in setting up the
global symbol tables as well, but I'm not a linker expert, so I won't do
more than conjecture here.
I would further conjecture that this is some of the reason that
libraries like libthread, libnsl, and maybe others have become "shells",
with all the real functionality in libc.
This is just my opinion, of course.
-- Garrett
> ----
>
> 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
