On Wed 23 Aug 2006 at 10:50PM, Mike Kupfer wrote:
> >>>>> "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes:
>
> Roland> An integration into SFW would make it FAR more difficult to
> Roland> convince other consolitations to use it
>
> Why? SFW is part of Solaris, after all (unlike the Companion CD). Why
> should other consolidations care which consolidation ksh93 comes from?
>
> Roland> An integration just into SFW would also mean that we can
> Roland> completly abandon most of the other long-term goals (even such
> Roland> low-hanging fruits like a common codebase for /usr/bin/printf,
> Roland> /usr/bin/sleep, /usr/bin/cat, /usr/bin/wc etc. etc. will become
> Roland> difficult as these tools [live] in OS/Net)
>
> I'm not sure everyone on the list will follow that argument, so I want
> to back up for a moment and fill in a couple details, because I think
> it's a good point. (If it's obvious to you what Roland's talking about,
> feel free to ignore the rest of this email.)
>
> ksh93 comes with a large set of built-in commands. The advantage of
> having so many built-ins is performance. But we want to avoid code
> duplication, which means structuring the built-ins and the standalone
> binaries to use common code. This will be more of a hassle if ksh93 is
> in SFW, because it probably would involve exposing private interfaces
> across a consolidation boundary.
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?
I agree that if we're going to go replace wc, etc. with things from
ksh, then there may well be a compelling argument to bringing this
stuff into ON, since the level of mixing will be high.
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).
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
