On Thu 24 Aug 2006 at 06:46AM, Roland Mainz wrote:
> >
> > I think Alan, Jim and I have clearly articulated at least two clean
> > ways to do this with expediency and minimal suffering.
>
> But both proposals do not gurantee the full binary compatibility... ;-/
Binary compatibilty for whom? We've already had that discussion: unless
I am mistaken, there is no externally facing interface here, and hence
there is nothing to be binary compatible with:
# pvs /usr/lib/libcmd.so.1
libc.so.1 (SUNW_0.7, SUNWprivate_1.1);
libcmd.so.1;
SUNWprivate_1.1;
> > As with many problems, you solve it in stages, not all at the same
> > time.
>
> I still think that such a work is just wasted engineering time. Do you
> have any _technical_ reasons why the Solaris libcmd functionlity should
See my question below and my point below about the larger architecture
of originated code vs imported code.
> Ok... thanks for the background information... however if you want an
> architectural "clean" solution we should move the |def*()|-functions to
> libcmdutils.so and not in yet-another new library.
That would be fine with me.
> > This is very different from the current situation: "liba and liba
> > have the same name, but are otherwise authored by different people,
> > are architecturally distinct, and have distinct consumers" which
> > appears to me to be the case before us.
>
> The last point isn't completely correct - both Solaris libcmd and
> ksh93's libcmd target commands as comsumers and at least the native
> Solaris command versions of the ksh93 builtin commands provided by
> libcmd have intersections - which quicky leads to the problem that
> future changes in this area may force us to make libcmd.so depend on
> liboldsolariscmdwithdeffunctions.so.666 ... ;-(
I had trouble working out which libcmd you meant in each part of the
sentence, so I am confused. You are saying that some of the
functionality x() in old-libcmd is also implemented as x() in new-libcmd
in a compatible way. Is that right? And...? I don't follow the next
part, or to which code "future changes" applies.
> > correct me I don't know of a specific policy which dictates that
> > cross-consolidation dependencies are inherently bad.
>
> Umpf... I've been instructed otherwise and IMO OS/Net should remain
> self-contained. It shouldn't really end like the DLL dependicy hell of
> "Gnome" or "X.org after the great modularisation" ... ;-(
By whom? I'd love to understand this more completely.
I'd note that 'make' is not part of OS/Net. Nor are the compilers.
> > Again, why? I don't see why the ksh93 must be in OS/Net to someday
> > deliver the file /usr/bin/ksh.
>
> Why isn't /sbin/sh then in /usr/sfw/bin/ ? Or /usr/bin/csh ? What about
> /usr/bin/bc ?
I thought about this exact question at some length this evening, since
I too was bothered by this. In the end, what I believe is that it is
important to consider what I'll call the "original source" of a blob of
code.
/bin/csh in a real sense *originates* from the OS/Net project (yes, it
originates from BSD, but the version from OpenSolaris is diverged and is
thus in a sense a unique software artifact). The kernel, libumem, ZFS,
libc and lots of other stuff are the same way. Other pieces like
kerberos are imported from the outside, but AFAIK undergo some
modification and/or are welded into the system in many places.
That said, it is a problem with my argument that parts of ON like
sendmail and perl do not originate in OpenSolaris: these are imported
into the source base, transformed in some way (so that they build as
part of OS/Net) and are then packaged. Personally I believe these are
grandfathered in, but I acknowledge that this belief may not be shared
by others.
It seems to me that this distinction of 'original' vs 'imported' code
also forms the basis of why I find the merging of libcmd and libcmd
frustrating.
As for inclusion into OS/Net, I'm only arguing that the bar be *higher*
for technology which does not originate in OS/Net. Why? By bringing it
into OS/Net, we force every OS/Net developer to compile it. It swells
the size of the OS/Net consolidation, and it binds together the version
of the component to the version of OS/Net when no such binding is
warranted. (I have thoughts about how this might impact OpenSolaris
distro builders, but I'm going to ponder them some more).
Now perhaps in the case of ksh93 (especially if it is /usr/bin/ksh),
this higher bar *is* reached: and that is what I want to understand. I
think Mike's comments about reimplenting wc, printf, etc. could form the
basis of a more firm rationale, and I'd like to hear more.
To ask a related informational question: will ksh93 be ARC'd as
External, or Committed? (or something else?)
> And how should the version in the SFW consolidation be build ? How
> should it be handled ? I started this project to get ksh93 integrated
> into OS/Net that it can replace at some point the old ksh. An
> integration into SFW would make it FAR more difficult to convince other
> consolitations to use it and a replacement of /usr/bin/ksh will likely
> become IMPOSSIBLE.
I think you may have some assumptions or some facts about SFW which I
(and I suspect others) do not understand.
To take a step back, you've articulated that some of the things I've
asked about stand in the way of making ksh = ksh93 is script
compatibility for customers and ISV products (which I don't want to open
as a question here. I'll leave that to the true ksh experts and to
PSARC).
> > I am just trying to make sure that the plan here makes sense. If you
> > convince me, I can hopefully be a helpful ally in helping you finish.
>
> Yes, but you're giving me a hard time... total time to answer all emails
> in this matter today: More than six hours... ;-((
I don't know what to tell you. It sounds like you are saying: this
discussion has insufficient value to continue. If you're saying that
email is too slow, and would like me to set up a conference call, I will
be happy to try to work out how to do that (I don't know how to do an
international one).
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
