Roland Mainz wrote:
> Richard Lowe wrote:
>
>> James Carlson wrote:
>>
>>> Roland Mainz writes:
>>>
>>>> ... the other items include less controversial things - like sticking a
>>>> "-xtrconst" to all SUNWonbld build tools (and some other places, IMO we
>>>> should make a list of commands which are run very often and check how
>>>> the performance can be improved (options include the usage of
>>>> "-xtrconst", lazyload, I/O via libast etc.)), cleanup some scripts etc.
>>>>
>>> That sounds quite useful.
>>>
>> I would want more justification than "quite useful" before libasts stdio
>> bits started being bolted to things.
>>
>
> libast contains more than the "stdio" bits...
> ... however I am suprised (or better: shocked... ;-( ) that people now
> starts throwing giant bricks in our direction. I thought it was very
> clear after the first ARC case that libast gets introduced into OS/Net
> that other Solaris applications can use it later...
>
First, Roland, IMO, you're making a mountain out of a molehill. (Or
maybe a giant brick out of a small pillow?) I think some justification
for _any_ change is useful.
As to this particular case, I feel limited use in some applications is a
different proposition than globally searching ON and converting most of
it wholesale. In the former case, limited library use makes sense, in
the latter case maybe this functionality really should be part of libc.
As to whether there should be a giant paradigm shift towards some common
stdio from what we are doing, I agree with the original poster that
"justification is required". Why would we want to change? What are the
benefits? And the costs? From what I've seen so far, you have a
tendency to see costs vs. benefits with a certain subjective view, that
doesn't necessarily concern all use cases (e.g. not all Solaris users
are writing ksh scripts that need to work with terabytes of data.)
Examination of the tradeoffs for major changes is certainly, IMO, warranted.
See my earlier message for more details.
-- 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
