Some of these general issues have been discussed before regarding 'top vs. prstat', but I don't have the thread handy, nor do I think it's worth rehashing the issue quite yet.
Regardless of the tool, the underlying interfaces need to be developed. The first step is to develop such an interface, as I don't consider any userland program (apart from a debugger like mdb) that grovels through /dev/kmem as sustainable. Once such an interface exists, we can evaluate the tradeoffs between developing our own tool or adapting lsof to use the new interfaces. All the points Dan outlines below are worth considering. Can we provide a better experience with a new tool? Is the existing tool a defacto standard? Will it be painful for new users to learn? How much engineering cost is associated with each task? I'd really like to see a suitable interface first, as my main gripe with lsof is the dependency on /dev/kmem - it makes it nearly impossible to track incompatible changes. Provided that is fixed, I think it becomes a much more realistic discussion regarding which path to take. - Eric On Mon, Oct 08, 2007 at 02:38:29PM -0400, Dan McDonald wrote: > 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 > _______________________________________________ > observability-discuss mailing list > observability-discuss at opensolaris.org -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
