src/lib/libutil/Makefile, branch release/8.2.0_cvs

Copy releng/8.2 to release/8.2.0 for 8.2-RELEASE.

2011-02-16T16:18:46+00:00

Approved by:	re (implicit)

This commit was manufactured to restore the state of the 8.2-RELEASE image.

Bump the version of all non-symbol-versioned shared libraries in

2009-07-19T17:25:24+00:00

preparation for 8.0-RELEASE.  Add the previous version of those
libraries to ObsoleteFiles.inc and bump __FreeBSD_Version.

Reviewed by:    kib
Approved by:    re (rwatson)

Add filler man pages for the kinfo functions I added recently.

2008-12-07T03:33:36+00:00

While here, hook up the hexdump(3) man page which wasn't being installed.

Merge user/peter/kinfo branch as of r185547 into head.

2008-12-02T06:50:26+00:00

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.

Fixed style issues with variable ordering and naming, spacing and

2008-11-23T23:26:12+00:00

parentheses.

Fixed alignment issue in gr_dup() in its assignment of gr_mem using a
struct to force alignment without performing alignment mathematics.  This
was noticed recently with libutil was built with WARNS=6 on platform such
as sparc64.

Added checks to gr_dup(), gr_equal() and gr_make() to prevent segfaults
when examining struct group's with the struct members pointing to NULL's.

With fix of alignment issue, restore WARNS?=6.

Reviewed by:	des
MFC after:	1 week

Comment out WARNS. There are too many alignment issues in libutil.

2008-11-05T11:06:10+00:00

Disconnect gr_util.c from the build. It isn't documented or used anywhere

2008-11-05T10:45:39+00:00

in the tree, and due to unsafe pointer arithmetic, it will most likely crash
on architectures with strict alignment requirements.

libutil now builds at WARNS level 6.

2008-11-04T13:51:15+00:00

MFC after:	3 weeks

Merge hexdump(9) to userland as hexdump(3) in libutil. I'm tired of doing

2008-07-01T22:30:57+00:00

this by hand in userland utilities.

MFC after:	1 month

Add four utility functions related to struct grp processing modeled in-part

2008-04-23T00:49:13+00:00

after similar calls related to struct pwd in libutil/pw_util.c:
  - gr_equal()
    Perform a deep comparison of two struct grp's.  It does a thorough, yet
    unoptimized comparison of all the members regardless of order.

  - gr_make()
    Create a string (see group(5)) from a struct grp.

  - gr_dup()
    Duplicate a struct grp.  Returns a value that is a single contiguous
    block of memory.

  - gr_scan()
    Create a struct grp from a string (as produced by gr_make()).

MFC after:	3 weeks