Dan Price wrote: > On Fri 25 Aug 2006 at 04:03AM, Roland Mainz wrote: > > > > > > I didn't fully follow it, so thanks for the clarification, Mike. > > > > > > I guess while I'm a fan of having an up-to-date ksh implementation, > > > I'm unsure of the architectural direction of implementing various > > > other system commands in terms of it. > > > > > > To what degree are we making architectural decisions about a large > > > swath of our base userland utilities here? > > > > We don't make this kind of decision now, e.g. we will NOT do that for > > the first putback. We'll come back when we're done - however some > > low-hanging fruits like getting /usr/bin/sleep and /usr/bin/pwd to use > > the libshell builtin versions would be easy (and is somewhere high on my > > ToDo list) and would even fix the problems that the current Solaris > > "sleep" version has no floating-point support (e.g. % /usr/bin/sleep 0.1 > > # doesn't work outside ksh93 right now) and that /usr/bin/pwd misses the > > very common "-P" and "-L" options (e.g. those two commands would be the > > "pathfinders" for the later work)... > > [I'll state up front that I haven't seen your ARC case draft-- I did > try to search for a copy on the forum, but failed to find a copy.]
We're going to release one soon... the draft is AFAIK almost finished. > You are stating that the decision to be in ON is based on the argument > that it is a foundation for future projects you intend to do. That is a > good point-- it architecturally supports your decision. > > In my mind, it also means that you need to disclose (at least at a high > level) to the ARC the larger architecture you are proposing. Otherwise, > it is difficult to assess the work. Before you answer, I'd appreciate > hearing from the ARC members on the list whether they agree that it is > in scope to hear about the larger architecture. To me, it is, since in > part it determines your choice of venue (ON or SFW) and potentially > other decisions, such as your interface stability. They may not agree > with me (please note that I am neither a member nor an intern of PSARC). Please note that there is no "master plan" or something like that. There are lots of ideas what we can do, but for now it simply looks like this: We integrate ksh93/libshell and the required libraries (libdll, libcmd, libast) into OS/Net and then try to attract other developers to check whether they can use it. We're then doing changes on demand (like adding threading and thread-safeness to libshell&co.) and incrementally work on figuring out what's needed, do modifications and increase stability levels of the APIs, implement applications etc. and work on the migration of /usr/bin/ksh to ksh93 This is more like a "bazaar" where ideas/needs/problems are communicated and handled by more than one institution (e.g. Sun/OpenSolaris.org) and not a "cathedral" with one monolithic master plan where eveything has been planned ahead for the next five years. [snip] > If this is the case--- that a large swath of the technical community is > bought into implement-in-terms-of-ksh as a strategy--- **then** you have > my support for having this in ON. At that point, ksh93 becomes so > fundamental to what we're doing that we'll be better served by having it > in ON, since it is basically indivisible from the core system. What you are proposing doesn't make sense (al least for me). If we first discuss this like you are proposing we will have lots of discussions for the next months(!!) and not a single piece of working code in OS/Net - which also means there will be little testing, bugfixing, experimentation, feedback generation and other real work going on (note that we are already in this trap since the beginning of JUNE (almost three months now)). This is not how OpenSource should work. Really. I really opt for the solution to integrate the current codecase into OS/Net as soon as possible that we deliver useable bits for both those people who may be interested to take a look at it and actually deliver feedback to upstream (e.g. AT&T) for any neccesary adjustments after the first putback is done. > > > But then... wouldn't we be tying the implementation of wc, etc. > > > to the *private interfaces* of something which originates externally? > > > Is that architecturally sound? Would PSARC accept this (I ask because > > > I honestly don't know the answer). > > > > I think this is OK since we would move to one single source code base > > where the AST and Solaris commands have been syncronised in both source > > and functionality. That's why the Sun layers are currently looking into > > the details how Sun/OpenSolaris.org can contribute OS/Net bits back to > > AT&T under their own license (or dual-license it etc. - I am not a > > laywer and don't know how thos works). > > I think it is technologically feasible; but I don't know what new > maintenance burdens it could incur, or how this might impact our ability > to be standards compliant or feature rich. Erm, actually one of the ideas is to lower the maintaince burden... > On a related note, what > happens if I want to add a new flag to 'cp', or 'wc'? ksh93/AST (including the builtin commands) implements the POSIX standard. We can add switches as much as we want - if they are incompatible (to POSIX) or problematic for other plaftforms we can simply to a #ifdef SOLARIS ... #endif in the matching code or bind those builtins to the matching path (e.g. /usr/bin/ for normal commands, /usr/xpg4/bin/ and /usr/xpg6/bin/ for commands if they need to be there because the command in /usr/bin/ works differently). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
