Re: bin/161257: procstat(1): procstat should grow a -l flag to

The following reply was made to PR bin/161257; it has been noted by GNATS.

From: Mikolaj Golub <trociny@freebsd.org>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: John Baldwin <jhb@freebsd.org>,  bug-followup@freebsd.org,  Robert Watson <rwatson@freebsd.org>
Subject: Re: bin/161257: procstat(1): procstat should grow a -l flag to display resource limits
Date: Sat, 05 Nov 2011 18:06:10 +0200

 On Sat, 5 Nov 2011 16:08:39 +0200 Kostik Belousov wrote:

  KB> On Sat, Nov 05, 2011 at 02:45:03PM +0200, Mikolaj Golub wrote:
  >> Hi,
  >> 
  >> Here is the patch that does 'procstat -l'. 
  >> 
  >> Note, I had to change rlimit_ident[] from char * to const char * to make
  >> procstat compile without warnings.
  KB> Commit it as a separate change. Also, I suggest you to commit the sysctl
  KB> kern.proc. oids in advance to avoid conflicts with argv/env patches.

  KB> You just cannot stop ?

  KB> The intendation in the sysctl_kern_proc_rlimit local variables block 
  KB> is inconsistent. Err, it is inconsistent in the whole function.

  KB> Please note that we grow the count of resources supported, e.g.
  KB> we got RLIMIT_NPTS and RLIMIT_SWAP for 8.0. At least a comment near
  KB> RLIM_NLIMITS to point anybody adding a new resource, to the kern.proc.rlimit
  KB> handler, is useful. For the same reason, you can restructure the handler
  KB> to honour the sysctl oldsize (but this is not needed right now).

  KB> Not related to your patch: it seems that lim_fork() wants an assert
  KB> that processes locks are held. Also you can add a blank line after '{'
  KB> there too.

  KB> For the output format, I much prefer to have current and maximum
  KB> values be tab-separated, instead of slash.

 Thank you for your comments. Concerning this last one, all limits for a
 process are printed on the same line, as it is done for other stats (to have
 it readable when procstat is run with -a flag). So as for me having current
 and maximum values be tab-separated will make output less readable. Don't you
 agree?

 -- 
 Mikolaj Golub
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"