Josh, Rich, et al., > On 1/5/07, Rich Teer <[EMAIL PROTECTED]> wrote: > > On Fri, 5 Jan 2007, Christoph Hellwig wrote: > > > > > Note that lsof doesn't have to do kmem craling. For > example on Linux > > > it only uses proper procfs interfaces. As such proper > interfaces seem > > > to exist on Solaris as well for use with pfiles it > shouldn't be a problem > > > for people knowledgeable in this area to adjust lsof to > do the right > > > thin on Solaris aswell. > > > > Have we invited Vic Abel > > Vic's name is spelled 'Abell', two e-llll
I've been called worse. :-) No apology is necessary, Rich. > > (lsof's author) to join the OpenSolaris > > community? With the right support framework in place, he'd probably > > be the best person to make the required changes (in lsof anyway). > > Better: Sun could hire him! I am very happily retired and not looking for employment. But let me explain why lsof has continued to use /dev/kmem. The foremost reason is that I can test it as a guest on systems where I couldn't (or wouldn't want to) have root permission. Sys group membership is all I need and most administrators are willing to give that with a guest login. (I also have a innate distaste for setuid(root) programs.) There are other reasons, however. On Linux, for example, which was cited as prototypical reason for using the Solaris /proc, lsof isn't fully capable in one important respect, because of a deficiency in the Linux /proc file system. It can't deliver current file position (as found in the file structure), so lsof can't report it, something I have found extremely valuable when using lsof to watch a file's progress -- e.g., growth. A second example is the HP-UX PSTAT extensions for lsof in whose development I played a direct role. Bugs have surfaced in that interface over the several years lsof has been using it and one significant one has been the subject of considerable discussion between me, customers and HP. After over a year of that, I think the bug may have finally been accepted as a bug and may even get fixed. Those two examples show that API's have their own limitations, primarily sluggish response to necessary fixes. At one time I proposed to Sun the construction of an lsof API for Solaris, but that proposal never went anywhere. I made it right after completing the HP PSTAT API, thinking its existence might be a sufficient prod. Now that I have struggled getting HP to fix a simple PSTAT bug for a year, my enchantment with lsof APIs has lost some of its edge. Having said all that, I would be interested in joining in some sort of effort to make lsof a part of OpenSolaris. Regards, Vic Abell, lsof author _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
