On Wed, 14 Nov 2007, Skip Ford wrote:
Robert Watson wrote:
On Tue, 13 Nov 2007, Yuri wrote:
Thank you for letting me know about this new feature procstat.
But is there any workaround in 6.3? I need to port one package that needs
to lookup file names by FDs to the current FreeBSD and need some solution
now.
If the port uses a script to extract the data, a tool like lsof may do the
trick. However, I'm not sure there are any native APIs to query that data
"as shipped" in 6.3. Once I've had some reasonable feedback on
procstat(1),
Well, the header file procstat.h is still missing from the tarball AFAICT so
I don't know how many people are using it.
Whoops! While you have obviously extracted or recreated the file, here's a
URL for everyone else:
http://www.watson.org/~robert/freebsd/20071115-procstat.tgz
Not sure what type of feedback you want, but I've been using it since you
posted the link and it works as advertised. I like being able to see the vm
map without using procfs.
Yeah, that was pretty much the motivation. I also plan to add the ability to
dump signal handler disposition information.
I don't like having a procstat(1) utility along with a ps(1) utility.
"procstat" seems short for process status as does "ps". Seems like
procstat(1) should be a library with ps(1) the frontend, or ps(1) should be
merged with procstat(1).
Plus, the name "procstat" sounds an awful lot like a certain part of the
body that makes me uncomfortable in my chair. Do you really want to spend
the rest of your life asking people to see their procstat output? ;-)
You are more evil than previously understood. :-)
I agree regarding the duplication with ps(1) -- however, I'm generally of the
opinion that ps(1) is overburdened as tools go, and that the goals are
actually somehwat different--procstat(1) intentionally doesn't have the
ability to generate a list of processes, for example, taking pids explicitly
as the argument; likewise, historically ps(1) has not been interested in
printing more than one line per process (although I think -h changed this).
I'll do a bit more investigation as to how easily it can be wedged in, and do
recognize the concern here.
But, it works fine and provides access to information that's not readily
available by other means.
Thanks for the feedback (working fine is useful feedback),
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
