Mike Kupfer wrote:
>
> >>>>> "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes:
>
> Alan> OS/Net is a Consolidation, ksh93 is a Project. If you wanted free
> Alan> reign to use throughout OS/Net, it would be Consolidation Private,
> Alan> not just Project Private.
>
> Roland> Unless we move the matching tools (e.g. "pwd", "sleep" etc.) to
> Roland> the ksh93-integration project, right ? :-)
>
> Roland> CC:'ing Mike Kupfer for help since at least "sleep" is one of
> Roland> the near-term projects which follows almost immediately after
> Roland> the initial ksh93-integration putback...
>
> Restructuring various standalone commands to have a tighter binding to
> ksh93 is certainly something that we've talked about, but not in much
> detail ("future work"). Based on hallway conversations, I expect such a
> restructuring to be controversial.
Why ? The "tighter binding" is thought to be an implementation detail.
Why is this controversial ? AFAIK the alternative would be that we need
two parallel implementations which would at least consume more memory,
disk space and engineering time...
Note that the current /usr/bin/ksh does the same - take a look at the
"alias.sh" script which links various tools like "kill", "test",
"umask", "jobs" etc. to /usr/bin/ksh - the "sleep" would do the same
(except that it calls the builtin command directly instead of going
through a shell script wrapper).
> So I'd prefer not to spend much time
> on this right now--it's likely to end up generating a lot of email and
> taking time away from the initial integration work.
... which we finish (hopefully) this month... after that we have to
start with the followup projects - for most of the smaller ones all the
patches have been written and we "only" have to ARC them...
> That said, I do have a few high-level comments about any restructuring
> work.
>
> First, it should be a full ARC case, not a fast-track.
I guess this would be the first OpenSolaris.org "full ARC case", right ?
> And you probably
> want to start with an inception review.
Did any other OpenSolaris.org project did such a thing yet ?
> This would happen early in the
> work--you might want to have a proof-of-concept implemented, but not
> much more than that. This is to minimize the amount of work that would
> have to be redone (or thrown away) if the ARC doesn't agree with your
> approach.
Well, the patch already sits in
http://bugs.grommit.com/show_bug.cgi?id=4
> Second, while the case can cover just "sleep", it should provide enough
> information to show that you have a workable plan for other commands.
What do you mean with provide "enougth information" ? So far the plan
looks like this: Check which ksh93/libcmd builtin commands can be used
in Solaris (assuming they have better/extended functionality over the
current Solaris versions) and then get rid of the "alias.sh" thing
(which would fix many bugs/RFEs as a sideeffect (like that /usr/bin/test
lacks support for hires timestamps, lacks floating-point support and is
horrible SLOW)).
> Third, using the Project Private stability level to justify the
> restructuring is the tail wagging the dog[1]. The restructuring needs
> to make sense on its own. Changing the stability level from Project
> Private to Consolidation Private is trivial.
I am not sure. Increasing the stability status by one level may backfire
since we may want to change the libshell API[1] soon to deal with the
lack of reentry/threadsafe capabilities of the current API (which
depends on global vars) - and I have zero clue what happens then... it
may or may not be problematic... long ago April said something about
that (which resulted in the choice of "project private" for the API) but
I can't remeber what her warning was... ;-(
BTW: There is a 3rd option: AFAIK projects can make "agreements" between
each other about using the other project's "private" API, right ?
> [1] My Cassell's dictionary translates this as "Das Unbedeutendste ist
> am Ruder".
Sounds Ok - but completely lacks the attribute "funny" of the
original... ;-(
BTW: Direct translation works, too: "Der Schwanz wedelt mit dem Hund"
:-)
[1]=I am thinking here about the API to create a |Shell_t| context
object. The API to access builtin commands in libshell/libcmd/etc. via
|b_foo(int ac, char *av[], void *context):| is rock-solid and stable
since many many years (and already transports a |Shell_t*| context which
means it carries anything we need).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
