On Mon, Oct 08, 2007 at 11:08:41AM -0700, Eric Schrock wrote:
> On Mon, Oct 08, 2007 at 01:49:08PM -0400, Brandorr wrote:
> > 
> > +1,000,000 for integrating LSOF. (My vote doesn't count, but I'm sure
> > you will find many others that will support/sponsor you if you choose
> > to take this on instead.)
> > 
> 
> Can you explain why '+1,000,000'?

I'm guessing because for better or for worse, every *other* UNIX-like, POSIX,
whatever-the-hell-you-want-to-call-it system has the LSOF tool integrated,
and ours doesn't.

There's a (much) bigger issue lurking here, and I'm sure it needs to be on a
list that's not just devoted to networking or observability.  OpenSolaris (or
Solaris, hang with me here) may have a tool that's different, possibly even
BETTER, than an equivalent tool for *BSD, Linux, AIX, etc.  As we wade out
more into the Open part of OpenSolaris, there may be a push for us to adopt a
tool everyone else is using, even though it may be distasteful to us, and may
cause a flag-day event for people using Solaris 10 or earlier versions of the
tool.

I see two immediately extreme answers to such a dilemma:

        1.) Accept the outside tool.  This can often cause a lot of developer
            suffering, e.g. Eric's point about providing LSOF a better
            user-kernel interface than /dev/kmem.  It *may* also compromise
            the integrity of the system, in our case, OpenSolaris.

        2.) Reject the outside tool.  More often than not this has been the
            path pre-Open Solaris took.  This can often cause user suffering,
            e.g. people have to remember what the &*^^&% the OpenSolaris
            version of <FOO> is.

There are paths in between to take, of course:

        * Dual-tool-stacks.  I suspect this will cause one of the stacks to
          degenerate over time, leading to one of the above extremes again.

        * Outside community engagement.  OpenSolaris contributes to the
          community of the outside tool, in hopes that changes can be made
          that preserve the integrity of both the tool and the OpenSolaris
          system.  (I hope to go down this path myself when cycles avail
          themselves for a specific protocol.)

        * Encouraging community acceptance of the inside tool.  Get the
          OpenSolaris tool out into wider use.  DTrace is an example of a
          success here.

        * Others I'm missing.

I'm not sure where this discussion about OpenSolaris vs. outside tools
belongs, but I'd appreciate a redirect.

Thanks,
Dan

Reply via email to