From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 18 21:01:30 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9282016A417 for ; Sun, 18 Nov 2007 21:01:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 680A813C459 for ; Sun, 18 Nov 2007 21:01:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5ED16474A2; Sun, 18 Nov 2007 16:03:37 -0500 (EST) Date: Sun, 18 Nov 2007 21:01:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Skip Ford In-Reply-To: <20071118204743.GE813@menantico.com> Message-ID: <20071118205541.U97497@fledge.watson.org> References: <1194980181.4739f355a32bc@webmail.rawbw.com> <20071114104157.D92502@fledge.watson.org> <20071114112304.GA835@menantico.com> <20071114121812.U2025@fledge.watson.org> <20071114132743.GB835@menantico.com> <20071116144356.S10677@fledge.watson.org> <20071116212342.GD835@menantico.com> <20071117215003.U53707@maildrop.int.zabbadoz.net> <20071117223910.GD813@menantico.com> <20071118151712.GA21185@voi.aagh.net> <20071118204743.GE813@menantico.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , freebsd-hackers@FreeBSD.org, Yuri Subject: Re: How to get filename of an open file descriptor X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2007 21:01:30 -0000 On Sun, 18 Nov 2007, Skip Ford wrote: > Thomas Hurst wrote: >> * Skip Ford (skip@menantico.com) wrote: >> >>> It would be interesting to know for sure, though, if Solaris uses >>> hardlinks and, if so, what their utility is called. >> >> Nope. They *do* use hardlinks in that they have 32bit wrappers in /usr/bin >> etc which dispatch to the relevent architecture, but the commands >> themselves are all seperate. > > Indeed, and each utility is quite complex as compared to what ours would be > if split. > > I would just rename procstat(1) to pargs(1) then hardlink the others since > ours are much less complex, but I'll take anything at this point. > > As for the procstat(1) code itself, I've found one bug and have two > sugestions: > > 1) procstat_args() doesn't use a local variable and the buffer doesn't > get cleared between calls: > > $ procstat -a 797 > PID ARGS > 797 audacious > $ procstat -a 795 797 > PID ARGS > 795 xterm -xtsessionID 11c0a80103000118536826300000007680000 > 797 audacious essionID 11c0a80103000118536826300000007680000 > $ > > Other option's functions are not similarly affected. > > 2) I think it should handle requests for information about pid 0 instead of > requiring at least pid 1 as it currently does. Solaris suggests '/proc/*' > to see all processes. If we use `ps axopid=` then it aborts on the swapper > (pid 0) immediately. > > 3) Similarly, I think all of the sysctl(3) calls within the individual > option functions (procstat_bin(), procstat_args(), etc.) should just go > ahead and print the header and pid, then print any sysctl(3) error in the > PID's row instead of erroring out. We're either about to finish executing > anyway if that was the only pid requested, or we're moving on to another pid > that has nothing to do with the previous pid. There's not really any reason > to stop processing further pids. This also affects attempting to list all > pids since it currently stops processing pids as soon as one doesn't exist. > A global error variable could just be incremented with every call and > returned at process exit, that way it'd still be meaningful for single PIDs. Actually, I think I've fixed all of the above in p4 with some changes yesterday; I'll do a new code drop for you to try: http://www.watson.org/~robert/freebsd/20071118-procstat.tgz The kernel patch is identical, so you can just rebuild procstat. > Since this is a per-process tool, I think it needs to complete "procstat -c > `ps axopid=`" if at all possible. Yes, I agree. Robert N M Watson Computer Laboratory University of Cambridge