From owner-freebsd-hackers  Sun Nov 19 21:49:41 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA10596
          for hackers-outgoing; Sun, 19 Nov 1995 21:49:41 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA10586
          for <hackers@FreeBSD.ORG>; Sun, 19 Nov 1995 21:49:24 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA32683; Mon, 20 Nov 1995 16:45:47 +1100
Date: Mon, 20 Nov 1995 16:45:47 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511200545.QAA32683@godzilla.zeta.org.au>
To: bde@zeta.org.au, taob@io.org
Subject: Re: panic: free vnode isn't
Cc: hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

>> Perhaps known bogus options should be checked for in a central source file:
>> 
>> #ifdef CHILD_MAX
>> #warning "bogus option CHILD_MAX, RTFM setrlimit(2), sh(1) (ulimit)"
>> #endif

>    CHILD_MAX (and I assume OPEN_MAX) is bogus now?  It was still in
>the LINT config as of 2.1.0-951026-SNAP...

It always was bogus.  Defining CHILD_MAX and OPEN_MAX in <limits.h>
informs interested applications that these limits are fixed.  Applications
can reasonably allocate arrays of size CHILD_MAX and OPEN_MAX at compile
time iff the limits are fixed.  This would break if someone increases the
limits.  Increasing the limits in the kernel config without increasing
them in <limits.h> and recompiling _all_ applications that include
<limits.h> increases your chances of breaking and application that depends
on fixed limits.  There seem to be few such applications.

>what is the recommended
>method for raising the default resource limits for a user then?

setrlimit(2) and sh(1) (ulimit).

Bruce