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.]
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).
I have to say that while I am a supporter of having ksh93 in
OpenSolaris-based distributions (including the one we call Solaris),
I am very frankly unconvinced about the larger "change userland to be
implemented in terms of ksh" architecture which you are proposing.
Have you obtained buy-in from the wider engineering community
for that larger architecture? What is the actual feasibility of
implementing something like 'cp' (which for example has a lot of
Solaris-ness in it) in terms of ksh? Do you have buy-in from
teams like ZFS, etc. about the use of libshell? Have April and
others from the commands team agreed that this architecture makes
sense?
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.
> > 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. On a related note, what
happens if I want to add a new flag to 'cp', or 'wc'?
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
