> 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'? Is it because it makes it possible to > >answer this particular question (what process is listening on a port), > >or is there some other greater functionality beyond pfiles(1) + this > >RFE that this would provide? > > > > It's *the* _standard_ tool for doing this kind of job. > Not having lsof is like being without bash and telling people > to use ksh (if that helps put the problem in perspective.) > > > >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 > >provide stable interfaces (or at last *an* interface that could be > >contracted) and modify the lsof code to use those, which is a > >non-trivial amount of work. > > > > > > Why not bundle lsof with the kernel and just require that it > is rebuilt and shipped out every time the kernel is patched? > > Darren
The larger point is that lsof is *one* tool, indeed very commonly used, to ask these questions. If we port lsof to the current kernel structures and it uses /dev/kmem, we solve that one problem, but no others -- namely, we don't create the ability for us to create any new tools or integrated functionality with our existing tool chain to addresses these questions, since we'd have to duplicate all the same kernel code. Also the notion of using /dev/kmem for this is brittle and state-inconsistent by definition since you're not grabbing locks. We need a generic facility for this, one that is not performance-prohibitive or state inconsistent. We could then convert lsof to use it and ship that as you suggest, and also open the door to a lot more interesting things than just lsof text output. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
