Mike Gerdts writes: > On 10/8/07, Eric Schrock <eric.schrock at sun.com> 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.) > > > > > > > RFE that this would provide? I ask because the interfaces lsof uses > > (namely /dev/kmem) are too brittle to suport in any coherent fashion. > > Integrating LSOF would be more than checking in code. We'd have to > > Given that lsof uses undocumented interfaces, it has a long history of > working quite well. The only time it has let me down in a big way is > with zones.
That's because there are multiple people (notably Casper Dik) who tweak the code with every small Sun patch or other change that breaks it. They're playing a game of catch-up with undocumented and often- changing interfaces. Don't mistake the apparent stability due to a great deal of effort for actual stability due to design. The two are different. > My vote would be for providing a useful interface that lsof could use > that is zone aware. One thing in particular about lsof compared to > the p* commands is that its output is easily parsed in scripts. > Multi-line output may be prettier for reading on a terminal, but I'm > much more likely to be reading such output after it has passed through > a pipe. Currently the p* commands tend to force the use of more/less > which is often times suboptimal. A different tack was proposed for "pport" in this thread. The output proposed was more like "pgrep," which is quite scriptable. That, at least, isn't a good reason to prefer lsof over the proposal that we've been discussing. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
