13 Commits

Author SHA1 Message Date
peter
184da5d83d Juggle some internal symbols from our antique zlib (that originally came
in from kernel-pppd which is long gone) so that ZFS and DTRACE play nice.

This is a horrible hack to get freefall to compile, and is in dire need
of reconciliation.  This antique zlib-1.04 code needs to go away.
2013-01-06 14:59:59 +00:00
tijl
a89581c07f Change some headers such that lang/gcc* ports no longer patch them.
The lang/gcc* ports patch headers where they think something is
non-standard. These patched headers override the system headers which means
you have to rebuild these ports whenever you do installworld to make sure
they contain the latest changes.
2012-02-14 12:50:20 +00:00
alfred
f34ce3dd38 Merge projects/enhanced_coredumps (r204346) into HEAD:
Enhanced process coredump routines.

  This brings in the following features:
  1) Limit number of cores per process via the %I coredump formatter.
  Example:
    if corefilename is set to %N.%I.core AND num_cores = 3, then
    if a process "rpd" cores, then the corefile will be named
    "rpd.0.core", however if it cores again, then the kernel will
    generate "rpd.1.core" until we hit the limit of "num_cores".

    this is useful to get several corefiles, but also prevent filling
    the machine with corefiles.

  2) Encode machine hostname in core dump name via %H.

  3) Compress coredumps, useful for embedded platforms with limited space.
    A sysctl kern.compress_user_cores is made available if turned on.

    To enable compressed coredumps, the following config options need to be set:
    options COMPRESS_USER_CORES
    device zlib   # brings in the zlib requirements.
    device gzio   # brings in the kernel vnode gzip output module.

  4) Eventhandlers are fired to indicate coredumps in progress.

  5) The imgact sv_coredump routine has grown a flag to pass in more
  state, currently this is used only for passing a flag down to compress
  the coredump or not.

  Note that the gzio facility can be used for generic output of gzip'd
  streams via vnodes.

Obtained from: Juniper Networks
Reviewed by: kan
2010-03-02 06:58:58 +00:00
imp
a50ffc2912 /* -> /*- for license, minor formatting changes 2005-01-07 01:45:51 +00:00
phk
4383144a9a Add one copy of crc32() and crc32_tab[] in libkern, and remove it two other
places.

Comment out crc32 related definitions in zlib.h, we don't seem to have the
corresponding code in our kernel.
2002-05-29 20:24:09 +00:00
trhodes
28d42899b7 More s/file system/filesystem/g 2002-05-16 21:28:32 +00:00
peter
15b9bcb121 Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL"
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot).  This is consistant with the other
BSD's who made this change quite some time ago.  More commits to come.
1999-12-29 04:46:21 +00:00
peter
3b842d34e8 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
dillon
dbf5cd2b57 Fix warnings in preparation for adding -Wall -Wcast-qual to the
kernel compile
1999-01-27 22:42:27 +00:00
peter
de12df2a1c Update kernel parts of ppp to ppp-2.3.3. Not much has changed except
that the deflate components use zlib 1.0.4 instead of zlib 0.95.
1998-03-21 20:56:16 +00:00
peter
3970ef2701 Update kernel parts of pppd from 2.2.0 to 2.3.0. I've yet to look at the
2.3.0 -> 2.3.1 changes, but I seem to recall that there are certain
"issues" with 2.3.1 (I'm not sure if it's just pppd or the whole lot, I
am not quite that far).  The present pppd seems to work with it just fine
for the time being.

Among the changes are that zlib (aka LZ77 aka deflate aka gzip) compression
is implemented as well as the original compress(1) LZW style.
1997-08-19 14:10:50 +00:00
peter
04ab5c8948 Send these files to the attic until they are in use for several reasons.
1: cvs and cvsup don't really support vendor branches other than 1.1.1.x,
this is on 1.1.2.x and causing problems in cvsup 'checkout mode', just the
same as cvs has problems interpreting dates. (cvs has "1.1.1" hard coded)
2: cvs 'rm'ing them takes them off the vendor branch and should hide the
above problems.
3: it's just clutter until the merge is done.
4: if the problem isn't sufficiently resolved by taking these off the
vendor branch, the files will have to be nuked and re-imported.
1997-07-05 15:44:29 +00:00
peter
87c1696b92 Initial revision 1997-07-01 20:44:10 +00:00