James Carlson wrote: > 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?
Maybe as a long-term project and assuming upstream (Glenn&&David) are Ok with such a move. For now this part of the API would just remain at a stability level to be used within OS/Net (e.g. private within OS/Net) > What applications ought to use it and are there some that should stay > away? Why can't we add the features to regular stdio Definately no. At least the Solaris implementation of stdio now suffers from many many years of backwards-compatibilty hacks and add-ones to a point where a rework from scratch may be easier than adding yet another set of features to stdio (uhm... the rework was already done: It's called "sfio"). Some of the features like using streams to write to a string buffer could be implemented as add-ons, but others like that "sfio" is largefile-aware by default and has no file descriptor limit will likely not work that easily (Ok, it could be done with more if() ... else ... if() ... else if() ... else ... hacks (and ignore some standards). The question is whether this additional complexity is still desired/usefull since it will bloat the test matrix even more). [snip] > > 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. AFAIK I never saw anything compareable in Solaris. There is an implementation of AVL trees somewhere but that is not what I was thinking about (for example the libast stacks can use files as backend storage and there is nothing compareable in Solaris nor Linux). BTW: I forgot a popular example: Solaris has regular expressions but the AST pattern matching code has a somewhat extended versions which accepts ~(mod)pattern modifiers where "mod" defines which pattern type "pattern" is (e.g. 'E' for extended regular expressions, 'G' for normal regular expressions, 'F' for plain strings, 'S' for shell pattern etc. etc). This could be implemented in libc at the expense of rewriting most of the pattern matching code in libc (this is a little bit more complex than it looks like since AST allows to mix&match pattern types). My question would be: Is that really neccesary to rewrite the code in libc just that some applications in OS/Net can use this extensions to patterns ? AFAIK it would be MUCH more economical to just use the libast code instead (which implements the varius features with POSIX as basis). > If the ones that are present aren't good enough, then > improve them. At what expense ? Just reinventing the wheel and improve things like the old Solaris stdio implementation or the Solaris libc regex pattern code is clearly BEYOND my powers as single contributor and I even doubt that a larger team of contributors would be successfull within a reasonable amount of time. I am not even employed to do it and most of the work is done beyond midnight (it's 04:08am right now). I can only use what is already there or write smaller bits myself. > 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. Uhm... libast is exactly ONE single library. And IMO the suggestion to move things from libast to libc sounds even more like that: Reinventing the wheel, something which wass IMHO done far too often in Solaris. [snip] > The only user today is ksh and ksh-related cohorts. Future users will > need ARC review, Why ? AFAIK it ONLY needs a matching stabilty level and then it can be used in other applications. AFAIK the remaining items are code review, not ARC review. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
