Roland Mainz writes: > 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")) ?
Sure -- I'm opposed because I don't see a need to reinvent this particular wheel. Yes, I understand that it has new features. Yes, I understand that it's purportedly faster. Yes, I understand that it has some advantages for porting. And, yes, I realize that it's a fundamental part of ksh93. What I'd want to see in a sfio-everywhere project is some broader statement of direction. Are we trying to push this as a standard? What applications ought to use it and are there some that should stay away? Why can't we add the features to regular stdio and how does this evolve in the long term? Do _all_ of those conditions hold true for _all_ of the features? Lacking that information, I don't see the point. (Please don't feel compelled to answer those questions now; they're things I'd want to see in the review of a concrete proposal.) > > (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)) ? The system already has common implementations of those data structures. If the ones that are present aren't good enough, then improve them. Don't just fork off in a new direction. That's basic system architecture. As a complex system, Solaris won't long survive if we don't limit the number of reinvented wheels it carries. Roland Mainz writes: > > 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. What "giant bricks?" Asking for more justification doesn't sound to me like throwing anything, much less a "giant brick." > 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... The only user today is ksh and ksh-related cohorts. Future users will need ARC review, and I see no indication that the project team intended to set any sort of precedent here for other applications. If you really see libast spreading far and wide for its advantages over libc, then that's something that needs to be addressed in an architectural review. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
