Searched hist:132 (Results 1 - 24 of 24) sorted by relevance

/freebsd-10.0-release/lib/libutil/
H A Dkinfo_getfile.cdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
H A Dkinfo_getvmmap.cdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
H A DMakefilediff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
H A Dlibutil.hdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
/freebsd-10.0-release/usr.bin/procstat/
H A DMakefilediff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
H A Dprocstat_vm.cdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
H A Dprocstat_files.cdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
/freebsd-10.0-release/sys/netgraph/bluetooth/include/
H A Dng_btsocket_rfcomm.hdiff 140027 Mon Jan 10 23:39:53 MST 2005 emax Make default RFCOMM session MTU match default L2CAP MTU.

This is just a workaround for a know problem with Motorola E1000
phone. Something is wrong with the configuration of L2CAP/RFCOMM
channel. Even though we set L2CAP MTU to 132 bytes (default RFCOMM
MTU 127 + 5 bytes RFCOMM frame header) and the phone accepts it,
the phone still sends oversized L2CAP packets. It appears that the
phone wants to use bigger (667 bytes) RFCOMM frames, but it does
not segment them according to the configured L2CAP MTU. The 667
bytes RFCOMM frame size corresponds to the default L2CAP MTU of
672 bytes (667 + 5 bytes RFCOMM frame header).

This problem only appears if connection was initiated from the
phone. I'm not sure who is at fault here, so for now just put
workaround in place. Quick look at the spec did not reveal any
anwser.

Tested by: Jes < jjess at freebsd dot polarhome dot com >
MFC after: 3 days
/freebsd-10.0-release/sys/dev/fb/
H A Dvesa.cdiff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes
work when using a graphics chipset which identifies itself as
`VIA CLE266', used in some VIA EPIA boards. Two values need to be
patched in the VESA mode information structure: the widths of the modes
mentioned above are encoded in a format which was unknown to the VESA
module (and to my copy of the VBE spec.) whereas the window memory
segment values seem to be just incorrect.

I tested this on a VIA EPIA-M9000 and -M10000.
diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes
work when using a graphics chipset which identifies itself as
`VIA CLE266', used in some VIA EPIA boards. Two values need to be
patched in the VESA mode information structure: the widths of the modes
mentioned above are encoded in a format which was unknown to the VESA
module (and to my copy of the VBE spec.) whereas the window memory
segment values seem to be just incorrect.

I tested this on a VIA EPIA-M9000 and -M10000.
diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes
work when using a graphics chipset which identifies itself as
`VIA CLE266', used in some VIA EPIA boards. Two values need to be
patched in the VESA mode information structure: the widths of the modes
mentioned above are encoded in a format which was unknown to the VESA
module (and to my copy of the VBE spec.) whereas the window memory
segment values seem to be just incorrect.

I tested this on a VIA EPIA-M9000 and -M10000.
diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes
work when using a graphics chipset which identifies itself as
`VIA CLE266', used in some VIA EPIA boards. Two values need to be
patched in the VESA mode information structure: the widths of the modes
mentioned above are encoded in a format which was unknown to the VESA
module (and to my copy of the VBE spec.) whereas the window memory
segment values seem to be just incorrect.

I tested this on a VIA EPIA-M9000 and -M10000.
diff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons.

- Handle pixel (raster text) mode properly.
- Clear screen and paint border right.
- Paint text attribute (colors).
- Fix off-by-one errors.
- Add some sanity checks.
- Fix some function prototypes.
- Add some comment lines.
- Define generic text mode numbers so that the user can just give
"80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol'
to change the current video mode. `vidoio.c' and `vesa.c' will map
these numbers to real video mode numbers appropriate and available
with the given video hardware. I believe this will be useful to make
syscons more portable across archtectures.
/freebsd-10.0-release/sys/dev/syscons/
H A Dscvesactl.cdiff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons.

- Handle pixel (raster text) mode properly.
- Clear screen and paint border right.
- Paint text attribute (colors).
- Fix off-by-one errors.
- Add some sanity checks.
- Fix some function prototypes.
- Add some comment lines.
- Define generic text mode numbers so that the user can just give
"80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol'
to change the current video mode. `vidoio.c' and `vesa.c' will map
these numbers to real video mode numbers appropriate and available
with the given video hardware. I believe this will be useful to make
syscons more portable across archtectures.
H A Dscvidctl.cdiff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons.

- Handle pixel (raster text) mode properly.
- Clear screen and paint border right.
- Paint text attribute (colors).
- Fix off-by-one errors.
- Add some sanity checks.
- Fix some function prototypes.
- Add some comment lines.
- Define generic text mode numbers so that the user can just give
"80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol'
to change the current video mode. `vidoio.c' and `vesa.c' will map
these numbers to real video mode numbers appropriate and available
with the given video hardware. I believe this will be useful to make
syscons more portable across archtectures.
H A Dsyscons.hdiff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons.

- Handle pixel (raster text) mode properly.
- Clear screen and paint border right.
- Paint text attribute (colors).
- Fix off-by-one errors.
- Add some sanity checks.
- Fix some function prototypes.
- Add some comment lines.
- Define generic text mode numbers so that the user can just give
"80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol'
to change the current video mode. `vidoio.c' and `vesa.c' will map
these numbers to real video mode numbers appropriate and available
with the given video hardware. I believe this will be useful to make
syscons more portable across archtectures.
H A Dsyscons.cdiff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons.

- Handle pixel (raster text) mode properly.
- Clear screen and paint border right.
- Paint text attribute (colors).
- Fix off-by-one errors.
- Add some sanity checks.
- Fix some function prototypes.
- Add some comment lines.
- Define generic text mode numbers so that the user can just give
"80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol'
to change the current video mode. `vidoio.c' and `vesa.c' will map
these numbers to real video mode numbers appropriate and available
with the given video hardware. I believe this will be useful to make
syscons more portable across archtectures.
/freebsd-10.0-release/bin/ls/
H A Dls.cdiff 5158 Sun Dec 18 17:00:01 MST 1994 joerg Make ls recognize the COLUMNS environmental variable, even
in cases where it does not run on a terminal. This is important
e.g. for commands like

env COLUMNS=132 ls -CR | lpr -Psome-wide-printer
/freebsd-10.0-release/sys/dev/sound/pci/
H A Demu10k1.cdiff 153799 Wed Dec 28 15:57:36 MST 2005 netchild Fix the order of the stereo channels (left <-> right).

From the PR:
---snip---
I think I have found the change which reversed the channels.
Revision 1.44 of emu10k1.c, which added Audigy support, has the line

emu_wrptr(sc, v->vnum, FXRT, 0xd01c0000);

replaced with the following lines:

if (sc->audigy) {
emu_wrptr(sc, v->vnum, A_FXRT1, v->fxrt1);
emu_wrptr(sc, v->vnum, A_FXRT2, v->fxrt2);
emu_wrptr(sc, v->vnum, A_SENDAMOUNTS, 0);
}
else
emu_wrptr(sc, v->vnum, FXRT, v->fxrt1 << 16);

where v->fxrt1 << 16 == 0xd10c0000

I don't have Audigy, so I'm not sure if the problem affects Audigy cards
too. The order of the channels can't be tested by just altering mixer
settings. Here's a small program to test if the channels are reversed on
your sound card:

#include <sys/soundcard.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
int fd = open("/dev/dsp", O_WRONLY), format = AFMT_S16_LE;
int channels = 2, rate = 22050, i;

/* 450 Hz sine wave on left channel, right channel silent */
unsigned char samples[] = {0, 0, 0, 0, 94, 16, 0, 0, 120, 32, 0, 0,
9, 48, 0, 0, 208, 62, 0, 0, 143, 76, 0, 0, 12, 89, 0, 0, 19, 100,
0, 0, 117, 109, 0, 0, 11, 117, 0, 0, 182, 122, 0, 0, 92, 126, 0,
0, 239, 127, 0, 0, 105, 127, 0, 0, 202, 124, 0, 0, 32, 120, 0, 0,
124, 113, 0, 0, 251, 104, 0, 0, 193, 94, 0, 0, 249, 82, 0, 0,
212, 69, 0, 0, 138, 55, 0, 0, 85, 40, 0, 0, 120, 24, 0, 0, 51, 8,
0, 0, 205, 247, 0, 0, 136, 231, 0, 0, 171, 215, 0, 0, 118, 200,
0, 0, 44, 186, 0, 0, 7, 173, 0, 0, 63, 161, 0, 0, 5, 151, 0, 0,
132, 142, 0, 0, 224, 135, 0, 0, 54, 131, 0, 0, 151, 128, 0, 0,
17, 128, 0, 0, 164, 129, 0, 0, 74, 133, 0, 0, 245, 138, 0, 0,
139, 146, 0, 0, 237, 155, 0, 0, 244, 166, 0, 0, 113, 179, 0, 0,
48, 193, 0, 0, 247, 207, 0, 0, 136, 223, 0, 0, 162, 239, 0, 0};

ioctl(fd, SNDCTL_DSP_SETFMT,&format);
ioctl(fd, SNDCTL_DSP_CHANNELS,&channels);
ioctl(fd, SNDCTL_DSP_SPEED,&rate);

for(i=0;i<500;i++)
write(fd, &samples, sizeof(samples));
write(fd, &samples, 2); /* swap channels */
for(i=0;i<500;i++)
write(fd, &samples, sizeof(samples));

return 0;
}

You should hear a sound on the left channel followed by a sound on the
right channel. If you hear a sound on the right channel first, the
channels are reversed.
---snip---

Owners of an audigy card should verify if it DTRT and report back.

Noticed by: Matthias Buelow <mkb@mukappabeta.de>
Submitted by: Juha-Matti Tilli <juhis@nallukka.net>
PR: 72221
/freebsd-10.0-release/share/termcap/
H A Dtermcap.srcdiff 102279 Thu Aug 22 17:48:13 MDT 2002 schweikh 1) add mvterm
2) add 132 column entries for VESA
3) fix kterm entry tc

PR: 1) misc/39628, 2) conf/13918, 3) misc/22660
Submitted by: 1) Daniel Rudy <dcrudy@pacbell.net>
Submitted by: 2) Martin Kammerhofer <dada@sbox.tu-graz.ac.at>
Submitted by: 3) Koji Mori <mori@tri.asanuma.co.jp>
MFC after: 2 weeks
/freebsd-10.0-release/sys/amd64/amd64/
H A Dsys_machdep.cdiff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall
argument definitions outside of the function parameter list. This is
to reduce the copious warning messages that (non-Jolitz) gcc produces.
Also fixed some bogus variable declarations and casts to make the
compiler happy.
H A Dmachdep.cdiff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall
argument definitions outside of the function parameter list. This is
to reduce the copious warning messages that (non-Jolitz) gcc produces.
Also fixed some bogus variable declarations and casts to make the
compiler happy.
/freebsd-10.0-release/sys/dev/puc/
H A Dpucdata.cdiff 237357 Thu Jun 21 02:58:50 MDT 2012 fjoe Remove Moxa CP-132EL definition (RS422/485-only board).
/freebsd-10.0-release/sys/i386/i386/
H A Dsys_machdep.cdiff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall
argument definitions outside of the function parameter list. This is
to reduce the copious warning messages that (non-Jolitz) gcc produces.
Also fixed some bogus variable declarations and casts to make the
compiler happy.
H A Dmachdep.cdiff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall
argument definitions outside of the function parameter list. This is
to reduce the copious warning messages that (non-Jolitz) gcc produces.
Also fixed some bogus variable declarations and casts to make the
compiler happy.
/freebsd-10.0-release/sys/sys/
H A Dsysctl.hdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.
/freebsd-10.0-release/sys/net/
H A Droute.cdiff 133513 Wed Aug 11 15:26:56 MDT 2004 andre Convert the routing table to use an UMA zone for rtentries. The zone is
called "rtentry".

This saves a considerable amount of kernel memory. R_Zmalloc previously
used 256 byte blocks (plus kmalloc overhead) whereas UMA only needs 132
bytes.

Idea from: OpenBSD
/freebsd-10.0-release/sys/kern/
H A Dkern_proc.cdiff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head.

This changes struct kinfo_filedesc and kinfo_vmentry such that they are
same on both 32 and 64 bit platforms like i386/amd64 and won't require
sysctl wrapping.

Two new OIDs are assigned. The old ones are available under
COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface
was never actually released on 7.x.

The other main change is to pack the data passed to userland via the
sysctl. kf_structsize and kve_structsize are reduced for the copyout.
If you have a process with 100,000+ sockets open, the unpacked records
require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still
seriously unpleasant, but not quite as devastating). A similar problem
exists for the vmentry structure - have lots and lots of shared libraries
and small mmaps and its copyout gets expensive too.

My immediate problem is valgrind. It traditionally achieves this
functionality by parsing procfs output, in a packed format. Secondly, when
tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled
32 bit binary which ran directly into the differing data structures in 32
vs 64 bit mode. (valgrind uses this to track file descriptor operations
and this therefore affected every single 32 bit binary)

I've added two utility functions to libutil to unpack the structures into
a fixed record length and to make it a little more convenient to use.

Completed in 917 milliseconds