Re: svn commit: r228342 - head/contrib/tzcode/zic
On Thu, 8 Dec 2011, Pawel Jakub Dawidek wrote:
On Thu, Dec 08, 2011 at 02:40:46AM +, Eitan Adler wrote:
Log:
- set progname for use in usage()
Modified: head/contrib/tzcode/zic/zdump.c
==
--- head/contrib/tzcode/zic/zdump.c Thu Dec 8 00:56:23 2011
(r228341)
+++ head/contrib/tzcode/zic/zdump.c Thu Dec 8 02:40:46 2011
(r228342)
@@ -260,6 +260,7 @@ char * argv[];
register struct tm *tmp;
register struct tm *newtmp;
+ progname=argv[0];
INITIALIZE(cutlotime);
INITIALIZE(cuthitime);
#if HAVE_GETTEXT
It will good to to try to upstream it as this is contributed code.
This change doesn't seem to be consistent with the style of this file.
They use spaces around =.
Also, if this were not contrib'ed code, then using progname in it would
involve 2 layers of style bugs:
- user-visible layer: in FreeBSD, the program name printed by usage() is
literal and doesn't depend on the pathname with which the program was
invoked. In old versions of zdump in FreeBSD, one of the main changes
was to convert it to FreeBSD style. Old versions were also missing
the uninitialization of progrname, even in the vendor version:
% Index: zdump.c
% ===
% RCS file: /home/ncvs/src/usr.sbin/zic/zdump.c,v
% retrieving revision 1.1.1.4
% retrieving revision 1.9
% diff -r1.1.1.4 -r1.9
% ...
% 130d132
% static char *progname;
% 131a134
% static void usage(void);
% 160d162
% progname = argv[0];
% 163,164c165
% (void) printf(%s\n, elsieid);
% (void) exit(EXIT_SUCCESS);
% ---
% errx(EXIT_SUCCESS, %s, elsieid);
% 174,177c175
% (void) fprintf(stderr,
% _(%s: usage is %s [ --version ] [ -v ] [ -c cutoff ] zonename ...\n),
% argv[0], argv[0]);
% (void) exit(EXIT_FAILURE);
% ---
% usage();
% 204,207c202,205
% (fakeenv[0] = (char *) malloc(longest + 4)) == NULL) {
% (void) perror(progname);
% (void) exit(EXIT_FAILURE);
% }
% ---
% (fakeenv[0] = (char *) malloc((size_t) (longest +
% 4))) == NULL)
% errx(EXIT_FAILURE,
%_(malloc() failed));
% 266,270c264,265
% if (fflush(stdout) || ferror(stdout)) {
% (void) fprintf(stderr, %s: , argv[0]);
% (void) perror(_(Error writing standard output));
% (void) exit(EXIT_FAILURE);
% }
% ---
% if (fflush(stdout) || ferror(stdout))
% errx(EXIT_FAILURE, _(error writing standard output));
% 277a273,280
% static void
% usage(void)
% {
% fprintf(stderr,
% _(usage: zdump [--version] [-v] [-c cutoff] zonename ...\n));
% exit(EXIT_FAILURE);
% }
This change also breaks the vendor style, since it doesn't use an
excessive (void) cast on the fprintf() in usage().
The other changes mostly involve changing perror() and [f]printf() to
errx(). This is a user-visible change if the [f]printf() was to
stdout instead of stderr, and perhaps if errx() gives better formatting
than perror(). The current version uses the unportable errx() instead
of perror() plus exit(), but still uses [f]printf() instead of warnx()
when not exiting. I can't see any vendor version of it using cvs.
- FreeBSD and NetBSD programs never use progname = argv[0] or use
progname explicitly. They use getprogname(3). This is implemented
by setting a variable __progname to argv[0] in crt. The setting may
be changed by setprogname(3). This gives minor inconsistencies which
may be considered features: usage() always prints the literal program
name, while the errx() family uses getprogname() and this prints
argv[0] or whatever setprogname() changed __progname too.
Grepping for progname in /usr/src/*bin shows only a few violations of
the above rules:
% bin/chio/chio.c: from ET from EU to ET to EU [inv]\n,
getprogname(), cname);
% bin/chio/chio.c: getprogname(), cname);
% bin/chio/chio.c: getprogname(), cname);
% bin/chio/chio.c: (void) fprintf(stderr, usage: %s %s\n, getprogname(),
cname);
% bin/chio/chio.c: (void) fprintf(stderr, usage: %s %s\n, getprogname(),
cname);
% bin/chio/chio.c: (void) fprintf(stderr, usage: %s %s picker\n,
getprogname(), cname);
% bin/chio/chio.c: getprogname(), cname);
% bin/chio/chio.c: getprogname(), cname);
% bin/chio/chio.c: getprogname(), cname);
% bin/chio/chio.c: from ET from EU\n, getprogname(), cname);
% bin/chio/chio.c: arg1 arg2 [arg3 [...]]\n, getprogname());
chio doesn't look like FreeBSD sources. It came from NetBSD.
%
svn commit: r228349 - head/lib/libufs
Author: rmh
Date: Thu Dec 8 12:31:47 2011
New Revision: 228349
URL: http://svn.freebsd.org/changeset/base/228349
Log:
Make berase() work on platforms whose kernel lacks DIOCGDELETE ioctl.
Approved by: kib (mentor)
Modified:
head/lib/libufs/block.c
Modified: head/lib/libufs/block.c
==
--- head/lib/libufs/block.c Thu Dec 8 10:42:38 2011(r228348)
+++ head/lib/libufs/block.c Thu Dec 8 12:31:47 2011(r228349)
@@ -139,10 +139,56 @@ bwrite(struct uufsd *disk, ufs2_daddr_t
return (cnt);
}
+#ifdef __FreeBSD_kernel__
+
+static int
+berase_helper(struct uufsd *disk, ufs2_daddr_t blockno, ufs2_daddr_t size)
+{
+ off_t ioarg[2];
+
+ ioarg[0] = blockno * disk-d_bsize;
+ ioarg[1] = size;
+ return (ioctl(disk-d_fd, DIOCGDELETE, ioarg));
+}
+
+#else
+
+static int
+berase_helper(struct uufsd *disk, ufs2_daddr_t blockno, ufs2_daddr_t size)
+{
+ char *zero_chunk;
+ off_t offset, zero_chunk_size, pwrite_size;
+ int rv;
+
+ offset = blockno * disk-d_bsize;
+ zero_chunk_size = 65536 * disk-d_bsize;
+ zero_chunk = calloc(1, zero_chunk_size);
+ if (zero_chunk == NULL) {
+ ERROR(disk, failed to allocate memory);
+ return (-1);
+ }
+ while (size 0) {
+ pwrite_size = size;
+ if (pwrite_size zero_chunk_size)
+ pwrite_size = zero_chunk_size;
+ rv = pwrite(disk-d_fd, zero_chunk, pwrite_size, offset);
+ if (rv == -1) {
+ ERROR(disk, failed writing to disk);
+ break;
+ }
+ size -= rv;
+ offset += rv;
+ rv = 0;
+ }
+ free(zero_chunk);
+ return (rv);
+}
+
+#endif
+
int
berase(struct uufsd *disk, ufs2_daddr_t blockno, ufs2_daddr_t size)
{
- off_t ioarg[2];
int rv;
ERROR(disk, NULL);
@@ -151,8 +197,5 @@ berase(struct uufsd *disk, ufs2_daddr_t
ERROR(disk, failed to open disk for writing);
return(rv);
}
- ioarg[0] = blockno * disk-d_bsize;
- ioarg[1] = size;
- rv = ioctl(disk-d_fd, DIOCGDELETE, ioarg);
- return (rv);
+ return (berase_helper(disk, blockno, size));
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r228351 - in head: contrib/groff/tmac gnu/usr.bin/groff/tmac
Author: ru Date: Thu Dec 8 13:54:06 2011 New Revision: 228351 URL: http://svn.freebsd.org/changeset/base/228351 Log: Pull up vendor changes to mdoc(7). Modified: head/contrib/groff/tmac/doc-common head/contrib/groff/tmac/doc-syms head/contrib/groff/tmac/doc.tmac head/contrib/groff/tmac/groff_mdoc.man head/gnu/usr.bin/groff/tmac/mdoc.local Directory Properties: head/contrib/groff/ (props changed) Modified: head/contrib/groff/tmac/doc-common == --- head/contrib/groff/tmac/doc-common Thu Dec 8 13:45:32 2011 (r228350) +++ head/contrib/groff/tmac/doc-common Thu Dec 8 13:54:06 2011 (r228351) @@ -264,50 +264,72 @@ .ds doc-volume-as-algoralgor .ds doc-volume-as-amd64amd64 .ds doc-volume-as-amigaamiga +.ds doc-volume-as-amigappc amigappc .ds doc-volume-as-arc arc +.ds doc-volume-as-arm arm .ds doc-volume-as-arm26arm26 .ds doc-volume-as-arm32arm32 +.ds doc-volume-as-armish armish .ds doc-volume-as-atariatari +.ds doc-volume-as-aviion aviion +.ds doc-volume-as-beagle beagle .ds doc-volume-as-beboxbebox .ds doc-volume-as-cats cats .ds doc-volume-as-cesfic cesfic .ds doc-volume-as-cobalt cobalt .ds doc-volume-as-dreamcastdreamcast +.ds doc-volume-as-emipsemips .ds doc-volume-as-evbarm evbarm .ds doc-volume-as-evbmips evbmips .ds doc-volume-as-evbppc evbppc .ds doc-volume-as-evbsh3 evbsh3 +.ds doc-volume-as-ews4800mips ews4800mips .ds doc-volume-as-hp300hp300 .ds doc-volume-as-hp700hp700 .ds doc-volume-as-hpcarm hpcarm .ds doc-volume-as-hpcmips hpcmips .ds doc-volume-as-hpcshhpcsh +.ds doc-volume-as-hppa hppa +.ds doc-volume-as-hppa64 hppa64 .ds doc-volume-as-i386 i386 +.ds doc-volume-as-ia64 ia64 +.ds doc-volume-as-ibmnws ibmnws +.ds doc-volume-as-iyonix iyonix +.ds doc-volume-as-landisk landisk +.ds doc-volume-as-loongson loongson .ds doc-volume-as-luna68k luna68k +.ds doc-volume-as-luna88k luna88k .ds doc-volume-as-m68k m68k .ds doc-volume-as-mac68k mac68k .ds doc-volume-as-macppc macppc .ds doc-volume-as-mips mips +.ds doc-volume-as-mips64 mips64 .ds doc-volume-as-mipsco mipsco .ds doc-volume-as-mmeyemmeye .ds doc-volume-as-mvme68k mvme68k +.ds doc-volume-as-mvme88k mvme88k .ds doc-volume-as-mvmeppc mvmeppc .ds doc-volume-as-netwindernetwinder .ds doc-volume-as-news68k news68k .ds doc-volume-as-newsmips newsmips .ds doc-volume-as-next68k next68k .ds doc-volume-as-ofppcofppc +.ds doc-volume-as-palm palm .ds doc-volume-as-pc532pc532 .ds doc-volume-as-playstation2 playstation2 .ds doc-volume-as-pmax pmax .ds doc-volume-as-pmppcpmppc .ds doc-volume-as-powerpc powerpc .ds doc-volume-as-prep prep +.ds doc-volume-as-rs6000 rs6000 .ds doc-volume-as-sandpointsandpoint .ds doc-volume-as-sbmips sbmips +.ds doc-volume-as-sgi sgi .ds doc-volume-as-sgimips sgimips .ds doc-volume-as-sh3 sh3 .ds doc-volume-as-sharkshark +.ds doc-volume-as-socppc socppc +.ds doc-volume-as-solbournesolbourne .ds doc-volume-as-sparcsparc .ds doc-volume-as-sparc64 sparc64 .ds doc-volume-as-sun2 sun2 @@ -316,6 +338,8 @@ .ds doc-volume-as-vax vax .ds doc-volume-as-x68k x68k .ds doc-volume-as-x86_64 x86_64 +.ds doc-volume-as-xen xen +.ds doc-volume-as-zaurus zaurus . .de Dt . \ reset default arguments @@ -451,12 +475,16 @@ .ds doc-operating-system-NetBSD-3.0 3.0 .ds doc-operating-system-NetBSD-3.0.1 3.0.1 .ds doc-operating-system-NetBSD-3.0.2 3.0.2 +.ds doc-operating-system-NetBSD-3.0.3 3.0.3 .ds doc-operating-system-NetBSD-3.1 3.1 +.ds doc-operating-system-NetBSD-3.1.1 3.1.1 .ds doc-operating-system-NetBSD-4.0 4.0 .ds doc-operating-system-NetBSD-4.0.1 4.0.1 .ds doc-operating-system-NetBSD-5.0 5.0 .ds doc-operating-system-NetBSD-5.0.1 5.0.1 .ds doc-operating-system-NetBSD-5.0.2 5.0.2 +.ds doc-operating-system-NetBSD-5.1 5.1 +.ds doc-operating-system-NetBSD-6.0 6.0 . .ds doc-operating-system-OpenBSD-2.0 2.0 .ds doc-operating-system-OpenBSD-2.1 2.1 @@ -487,6 +515,8 @@ .ds doc-operating-system-OpenBSD-4.6 4.6 .ds doc-operating-system-OpenBSD-4.7 4.7 .ds doc-operating-system-OpenBSD-4.8 4.8 +.ds doc-operating-system-OpenBSD-4.9 4.9 +.ds doc-operating-system-OpenBSD-5.0 5.0 . .ds doc-operating-system-FreeBSD-1.0 1.0 .ds doc-operating-system-FreeBSD-1.1 1.1 @@ -544,6 +574,7 @@ .ds doc-operating-system-FreeBSD-8.0 8.0 .ds doc-operating-system-FreeBSD-8.1 8.1 .ds doc-operating-system-FreeBSD-8.2 8.2 +.ds doc-operating-system-FreeBSD-9.0 9.0
Re: svn commit: r228281 - in head/sys/dev: e1000 re
On 12/5/11 2:31 PM, Luigi Rizzo wrote:
On Mon, Dec 05, 2011 at 07:38:54PM +0100, Marius Strobl wrote:
On Mon, Dec 05, 2011 at 03:33:14PM +, Luigi Rizzo wrote:
...
+#ifdef DEV_NETMAP
+ if (slot) {
+ int si = i + na-tx_rings[txr-me].nkr_hwofs;
+ void *addr;
+
+ if (si= na-num_tx_desc)
+ si -= na-num_tx_desc;
+ addr = NMB(slot + si);
+ txr-tx_base[i].buffer_addr =
+ htole64(vtophys(addr));
+ /* reload the map for netmap mode */
+ netmap_load_map(txr-txtag,
+ txbuf-map, addr, na-buff_size);
+ }
+#endif /* DEV_NETMAP */
Can these vtophys(9) usages be fixed to use bus_dma(9) instead so netmap
works with bounce buffers, IOMMUs etc?
maybe. Can you suggest how to change it ?
Consider that (not here but in other places) vtophys() is called
in a time-critical loop so performance matters a lot. As long as i
can compute the physical address in advance and cache it in my own
array, i suppose that should be fine (in which case the calls to
vtophys(addr) would become NMPB(slot + si) where the NMPB() macro
would hide translations and checks.
For your use case, you probably don't want to be coping with bounce
buffers at all. That is, if you are preallocating long-lived buffers
that keep getting reused while netmap is active that are allocated at
startup and free'd at teardown, you probably want to allocate buffers
that won't require bounce buffers. That means you have to let the
drivers allocate the buffers (or give you a suitable bus_dma tag since
different devices have different addressing requirements, etc.). You
could then use bus_dmamem_alloc() to allocate your buffers.
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228281 - in head/sys/dev: e1000 re
On Thu, Dec 08, 2011 at 12:49:18PM -0500, John Baldwin wrote:
On 12/5/11 2:31 PM, Luigi Rizzo wrote:
On Mon, Dec 05, 2011 at 07:38:54PM +0100, Marius Strobl wrote:
On Mon, Dec 05, 2011 at 03:33:14PM +, Luigi Rizzo wrote:
...
+#ifdef DEV_NETMAP
+ if (slot) {
+ int si = i + na-tx_rings[txr-me].nkr_hwofs;
+ void *addr;
+
+ if (si= na-num_tx_desc)
+ si -= na-num_tx_desc;
+ addr = NMB(slot + si);
+ txr-tx_base[i].buffer_addr =
+ htole64(vtophys(addr));
+ /* reload the map for netmap mode */
+ netmap_load_map(txr-txtag,
+ txbuf-map, addr, na-buff_size);
+ }
+#endif /* DEV_NETMAP */
Can these vtophys(9) usages be fixed to use bus_dma(9) instead so netmap
works with bounce buffers, IOMMUs etc?
maybe. Can you suggest how to change it ?
Consider that (not here but in other places) vtophys() is called
in a time-critical loop so performance matters a lot. As long as i
can compute the physical address in advance and cache it in my own
array, i suppose that should be fine (in which case the calls to
vtophys(addr) would become NMPB(slot + si) where the NMPB() macro
would hide translations and checks.
For your use case, you probably don't want to be coping with bounce
buffers at all. That is, if you are preallocating long-lived buffers
that keep getting reused while netmap is active that are allocated at
startup and free'd at teardown, you probably want to allocate buffers
that won't require bounce buffers. That means you have to let the
drivers allocate the buffers (or give you a suitable bus_dma tag since
different devices have different addressing requirements, etc.). You
could then use bus_dmamem_alloc() to allocate your buffers.
certainly i don't want to use netmap with bounce buffers.
I am not sure about IOMMU (I basically don't need it but maybe
using a compatible API is always nice). Right now i am allocating
a huge chunk of memory with contigmalloc.
Ryan Stone suggested that a plain malloc may work as well (as long
as i make sure that each buffer is within a single page).
Eventually I may want to play with cache alignment (also suggested by Ryan)
so allocate smaller chunks of contigmalloc'ed memory (say each buffer
is 2K - 64 bytes, then a contiguous block of 64K fits exactly 33 buffers).
cheers
luigi
may also work as long as i make sure th
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228281 - in head/sys/dev: e1000 re
On 12/8/11 1:29 PM, Luigi Rizzo wrote:
On Thu, Dec 08, 2011 at 12:49:18PM -0500, John Baldwin wrote:
On 12/5/11 2:31 PM, Luigi Rizzo wrote:
On Mon, Dec 05, 2011 at 07:38:54PM +0100, Marius Strobl wrote:
On Mon, Dec 05, 2011 at 03:33:14PM +, Luigi Rizzo wrote:
...
+#ifdef DEV_NETMAP
+ if (slot) {
+ int si = i + na-tx_rings[txr-me].nkr_hwofs;
+ void *addr;
+
+ if (si= na-num_tx_desc)
+ si -= na-num_tx_desc;
+ addr = NMB(slot + si);
+ txr-tx_base[i].buffer_addr =
+ htole64(vtophys(addr));
+ /* reload the map for netmap mode */
+ netmap_load_map(txr-txtag,
+ txbuf-map, addr, na-buff_size);
+ }
+#endif /* DEV_NETMAP */
Can these vtophys(9) usages be fixed to use bus_dma(9) instead so netmap
works with bounce buffers, IOMMUs etc?
maybe. Can you suggest how to change it ?
Consider that (not here but in other places) vtophys() is called
in a time-critical loop so performance matters a lot. As long as i
can compute the physical address in advance and cache it in my own
array, i suppose that should be fine (in which case the calls to
vtophys(addr) would become NMPB(slot + si) where the NMPB() macro
would hide translations and checks.
For your use case, you probably don't want to be coping with bounce
buffers at all. That is, if you are preallocating long-lived buffers
that keep getting reused while netmap is active that are allocated at
startup and free'd at teardown, you probably want to allocate buffers
that won't require bounce buffers. That means you have to let the
drivers allocate the buffers (or give you a suitable bus_dma tag since
different devices have different addressing requirements, etc.). You
could then use bus_dmamem_alloc() to allocate your buffers.
certainly i don't want to use netmap with bounce buffers.
I am not sure about IOMMU (I basically don't need it but maybe
using a compatible API is always nice). Right now i am allocating
a huge chunk of memory with contigmalloc.
Ryan Stone suggested that a plain malloc may work as well (as long
as i make sure that each buffer is within a single page).
Eventually I may want to play with cache alignment (also suggested by Ryan)
so allocate smaller chunks of contigmalloc'ed memory (say each buffer
is 2K - 64 bytes, then a contiguous block of 64K fits exactly 33 buffers).
Right, you should use bus_dmamem_alloc() instead. Internally it calls
contigmalloc(). However, it will only allocate memory that your device
can safely use (so if you are using a NIC that can only do 32-bit DMA
addresses, it will allocate pages below 4GB avoiding bounce buffering).
For the IOMMU case it will usually allocate memory from the region
that is statically mapped into the IOMMU (at least some IOMMU's split
the DVMA address space into two types: a mostly static region for things
like descriptor rings, etc. and a dynamic region for transient I/O
buffers like mbufs). If you want to design an interface
that will work with a wide variety of hardware and not just ixgbe on
Intel, then using bus_dma to manage DMA buffers is the correct approach.
Also, back to IOMMU, if the device is doing DMA into this buffer, then
you _must_ use the IOMMU on certain platforms (e.g. sparc64, probably
some embedded platforms where netmap might be very nice to have).
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227956 - head/usr.bin/procstat
On 12/3/11 3:58 PM, Mikolaj Golub wrote: On Mon, 28 Nov 2011 13:30:11 -0500 John Baldwin wrote: JB On Thursday, November 24, 2011 3:54:06 pm Mikolaj Golub wrote: Author: trociny Date: Thu Nov 24 20:54:06 2011 New Revision: 227956 URL: http://svn.freebsd.org/changeset/base/227956 Log: usr.bin/procstat Add -l flag to display resource limits. PR:bin/161257 Reviewed by:kib MFC after:2 weeks JB Thanks for doing this! Did you consider making the procstat -l output use JB pretty output similar to the output of /usr/bin/limits? For example, JB using infinity instead of -1 and using humanize_number() for finite limits JB that are in units of bytes? I tried several variants, from one where for rlimit names rlimit_ident constants from sys/resource.h are used and units are printed as suffixes: PID COMM RLIMIT SOFT HARD 46150 zsh cpu 10S infinity 46150 zsh fsize infinity infinity 46150 zsh data 524288kB 524288kB 46150 zsh stack 65536kB65536kB 46150 zsh core 9765625kB 9765625kB 46150 zsh rssinfinity infinity 46150 zsh memlockinfinity infinity 46150 zsh nproc 5547 5547 46150 zsh nofile11095 11095 46150 zsh sbsize infinity infinity 46150 zsh vmem infinity infinity 46150 zsh npts infinity infinity 46150 zsh swap infinity infinity to one where rlimit names are the same as in limits(1) and units are printed in separate column: PID COMM RLIMIT SOFT HARD UNIT 48885 zsh cputime 10 infinity secs 48885 zsh filesize infinity infinity bytes 48885 zsh datasize524288k524288k bytes 48885 zsh stacksize65536k 65536k bytes 48885 zsh coredumpsize 95367M 95367M bytes 48885 zsh memoryuse infinity infinity bytes 48885 zsh memorylocked infinity infinity bytes 48885 zsh maxprocesses 5547 5547 48885 zsh openfiles 11095 11095 48885 zsh sbsize infinity infinity bytes 48885 zsh vmemoryuse infinity infinity bytes 48885 zsh pseudo-terminals infinity infinity 48885 zsh swapuseinfinity infinity bytes Personally I like the first variant as the most compact and the easiest to maintain but would be glad to learn what other think about this or may be have other suggestions. A couple other variations: PID COMM RLIMIT SOFT HARD UNIT 47062 zsh cpu 10 infinity secs 47062 zsh fsize infinity infinity bytes 47062 zsh data524288k524288k bytes 47062 zsh stack 67108864 67108864 bytes 47062 zsh core 9765625k 9765625k bytes 47062 zsh rssinfinity infinity bytes 47062 zsh memlockinfinity infinity bytes 47062 zsh nproc 5547 5547 47062 zsh nofile11095 11095 47062 zsh sbsize infinity infinity bytes 47062 zsh vmem infinity infinity bytes 47062 zsh npts infinity infinity 47062 zsh swap infinity infinity bytes PID COMM RLIMIT SOFT HARD UNIT 48798 zsh cputime 10 infinity secs 48798 zsh filesize infinity infinity bytes 48798 zsh datasize524288k524288k bytes 48798 zsh stacksize 65536k 65536k bytes 48798 zsh coredumpsize 95367M 95367M bytes 48798 zsh memoryuse infinity infinity bytes 48798 zsh memorylocked infinity infinity bytes 48798 zsh maxprocesses 5547 5547 48798 zsh openfiles 11095 11095 48798 zshsbsize infinity infinity bytes 48798 zshvmemoryuse infinity infinity bytes 48798 zsh pseudo-terminals infinity infinity 48798 zsh swapuse infinity infinity bytes Hmm, I would stick as close to limits output as possible. I would consider duplicating the unit field in each of soft and hard, so you end up with something like this: PID COMMRLIMIT SOFT HARD 48798 zsh cputime 10 secs
Re: svn commit: r227956 - head/usr.bin/procstat
On Thu, 08 Dec 2011 13:30:36 -0500 John Baldwin wrote: JB On 12/3/11 3:58 PM, Mikolaj Golub wrote: On Mon, 28 Nov 2011 13:30:11 -0500 John Baldwin wrote: JB On Thursday, November 24, 2011 3:54:06 pm Mikolaj Golub wrote: Author: trociny Date: Thu Nov 24 20:54:06 2011 New Revision: 227956 URL: http://svn.freebsd.org/changeset/base/227956 Log: usr.bin/procstat Add -l flag to display resource limits. PR:bin/161257 Reviewed by:kib MFC after:2 weeks JB Thanks for doing this! Did you consider making the procstat -l output use JB pretty output similar to the output of /usr/bin/limits? For example, JB using infinity instead of -1 and using humanize_number() for finite limits JB that are in units of bytes? I tried several variants, from one where for rlimit names rlimit_ident constants from sys/resource.h are used and units are printed as suffixes: PID COMM RLIMIT SOFT HARD 46150 zsh cpu 10S infinity 46150 zsh fsize infinity infinity 46150 zsh data 524288kB 524288kB 46150 zsh stack 65536kB65536kB 46150 zsh core 9765625kB 9765625kB 46150 zsh rssinfinity infinity 46150 zsh memlockinfinity infinity 46150 zsh nproc 5547 5547 46150 zsh nofile11095 11095 46150 zsh sbsize infinity infinity 46150 zsh vmem infinity infinity 46150 zsh npts infinity infinity 46150 zsh swap infinity infinity to one where rlimit names are the same as in limits(1) and units are printed in separate column: PID COMM RLIMIT SOFT HARD UNIT 48885 zsh cputime 10 infinity secs 48885 zsh filesize infinity infinity bytes 48885 zsh datasize524288k524288k bytes 48885 zsh stacksize65536k 65536k bytes 48885 zsh coredumpsize 95367M 95367M bytes 48885 zsh memoryuse infinity infinity bytes 48885 zsh memorylocked infinity infinity bytes 48885 zsh maxprocesses 5547 5547 48885 zsh openfiles 11095 11095 48885 zsh sbsize infinity infinity bytes 48885 zsh vmemoryuse infinity infinity bytes 48885 zsh pseudo-terminals infinity infinity 48885 zsh swapuseinfinity infinity bytes Personally I like the first variant as the most compact and the easiest to maintain but would be glad to learn what other think about this or may be have other suggestions. A couple other variations: PID COMM RLIMIT SOFT HARD UNIT 47062 zsh cpu 10 infinity secs 47062 zsh fsize infinity infinity bytes 47062 zsh data524288k524288k bytes 47062 zsh stack 67108864 67108864 bytes 47062 zsh core 9765625k 9765625k bytes 47062 zsh rssinfinity infinity bytes 47062 zsh memlockinfinity infinity bytes 47062 zsh nproc 5547 5547 47062 zsh nofile11095 11095 47062 zsh sbsize infinity infinity bytes 47062 zsh vmem infinity infinity bytes 47062 zsh npts infinity infinity 47062 zsh swap infinity infinity bytes PID COMM RLIMIT SOFT HARD UNIT 48798 zsh cputime 10 infinity secs 48798 zsh filesize infinity infinity bytes 48798 zsh datasize524288k524288k bytes 48798 zsh stacksize 65536k 65536k bytes 48798 zsh coredumpsize 95367M 95367M bytes 48798 zsh memoryuse infinity infinity bytes 48798 zsh memorylocked infinity infinity bytes 48798 zsh maxprocesses 5547 5547 48798 zsh openfiles 11095 11095 48798 zshsbsize infinity infinity bytes 48798 zshvmemoryuse infinity infinity bytes 48798 zsh pseudo-terminals infinity infinity 48798 zsh swapuse infinity infinity bytes JB Hmm, I would stick as
Re: svn commit: r227956 - head/usr.bin/procstat
On 12/8/11 3:53 PM, Mikolaj Golub wrote: On Thu, 08 Dec 2011 13:30:36 -0500 John Baldwin wrote: JB On 12/3/11 3:58 PM, Mikolaj Golub wrote: On Mon, 28 Nov 2011 13:30:11 -0500 John Baldwin wrote: JB On Thursday, November 24, 2011 3:54:06 pm Mikolaj Golub wrote: Author: trociny Date: Thu Nov 24 20:54:06 2011 New Revision: 227956 URL: http://svn.freebsd.org/changeset/base/227956 Log: usr.bin/procstat Add -l flag to display resource limits. PR:bin/161257 Reviewed by:kib MFC after:2 weeks JB Thanks for doing this! Did you consider making the procstat -l output use JB pretty output similar to the output of /usr/bin/limits? For example, JB using infinity instead of -1 and using humanize_number() for finite limits JB that are in units of bytes? I tried several variants, from one where for rlimit names rlimit_ident constants from sys/resource.h are used and units are printed as suffixes: PID COMM RLIMIT SOFT HARD 46150 zsh cpu 10S infinity 46150 zsh fsize infinity infinity 46150 zsh data 524288kB 524288kB 46150 zsh stack 65536kB65536kB 46150 zsh core 9765625kB 9765625kB 46150 zsh rssinfinity infinity 46150 zsh memlockinfinity infinity 46150 zsh nproc 5547 5547 46150 zsh nofile11095 11095 46150 zsh sbsize infinity infinity 46150 zsh vmem infinity infinity 46150 zsh npts infinity infinity 46150 zsh swap infinity infinity to one where rlimit names are the same as in limits(1) and units are printed in separate column: PID COMM RLIMIT SOFT HARD UNIT 48885 zsh cputime 10 infinity secs 48885 zsh filesize infinity infinity bytes 48885 zsh datasize524288k524288k bytes 48885 zsh stacksize65536k 65536k bytes 48885 zsh coredumpsize 95367M 95367M bytes 48885 zsh memoryuse infinity infinity bytes 48885 zsh memorylocked infinity infinity bytes 48885 zsh maxprocesses 5547 5547 48885 zsh openfiles 11095 11095 48885 zsh sbsize infinity infinity bytes 48885 zsh vmemoryuse infinity infinity bytes 48885 zsh pseudo-terminals infinity infinity 48885 zsh swapuseinfinity infinity bytes Personally I like the first variant as the most compact and the easiest to maintain but would be glad to learn what other think about this or may be have other suggestions. A couple other variations: PID COMM RLIMIT SOFT HARD UNIT 47062 zsh cpu 10 infinity secs 47062 zsh fsize infinity infinity bytes 47062 zsh data524288k524288k bytes 47062 zsh stack 67108864 67108864 bytes 47062 zsh core 9765625k 9765625k bytes 47062 zsh rssinfinity infinity bytes 47062 zsh memlockinfinity infinity bytes 47062 zsh nproc 5547 5547 47062 zsh nofile11095 11095 47062 zsh sbsize infinity infinity bytes 47062 zsh vmem infinity infinity bytes 47062 zsh npts infinity infinity 47062 zsh swap infinity infinity bytes PID COMM RLIMIT SOFT HARD UNIT 48798 zsh cputime 10 infinity secs 48798 zsh filesize infinity infinity bytes 48798 zsh datasize524288k524288k bytes 48798 zsh stacksize 65536k 65536k bytes 48798 zsh coredumpsize 95367M 95367M bytes 48798 zsh memoryuse infinity infinity bytes 48798 zsh memorylocked infinity infinity bytes 48798 zsh maxprocesses 5547 5547 48798 zsh openfiles 11095 11095 48798 zshsbsize infinity infinity bytes 48798 zsh
