[osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[Dave Marquardt]

"a" == a b <a> writes:

>> If you postulate that
>> 
>> 1) lsof is tightly bound to a particular kernel build,
>> 
>> 2) lsof behaves correctly on the kernel it was built for, and
>> 
>> 3) lsof will be rebuilt and redelivered in concert with
>> any and all new kernel builds
>> 
>> then there is no architectural problem with what your colleague suggests.
>> We tend to call such things "consolidation private dependencies" and
>> gleefully (for the ARCs at least) delegate the job of keeping the
>> producer (kernel) and consumer (lsof) working correctly to the people who
>> are responsible for delivering the consolidation itself...
>> 
>> Of course, if you can't guarantee #2 above, this won't work.

a> Just having to compile `lsof` every time the kernel rev changes is already
a> too much overhead. At any given day, there are many issues, feature
a> requests and fixes to the build, that it is really inefficient to have one
a> more thing to worry about -- some crappy utility written by an external 3rd
a> party whose only benefit is to show open ports and files.

It occurred to me that we might be able to leverage the CTF
information that mdb uses to decode structures in the kernel.
Unfortunately, last I looked, the CTF lookup code in mdb was not a
public interface, so I'm not sure we can go there at this point.  But
if we could, then we could use CTF to look up the structure definition
and avoid recompiling lsof (or some similar program).
-- 
Dave Marquardt
Sun Microsystems, Inc.
Austin, TX
+1 512 401-1077 (SUN internal: x64077)