> placed on the value should be similar/identical. Any differences in the
> way the value is treated should be well documented (or fixed). As we
> move into larger memory systems our current limitations need to be either
> removed or increased.
Yes, you are right. It doesn't make sense to restrict the value of maxusers
at configuration time, when the kernel can be configured to use larger values
at boot time.
I think it makes sense to remove the maximum bound on a statically
configured 'maxusers' value. The lower bound could be retained
as a sanity check.
Something like this?
Index: mkoptions.c
===================================================================
RCS file: /cvs/FreeBSD/src/usr.sbin/config/mkoptions.c,v
retrieving revision 1.30
diff -u -r1.30 mkoptions.c
--- mkoptions.c 15 Feb 2003 02:26:13 -0000 1.30
+++ mkoptions.c 5 Jul 2003 04:42:44 -0000
@@ -52,11 +52,7 @@
#include "config.h"
#include "y.tab.h"
-static struct users {
- int u_default;
- int u_min;
- int u_max;
-} users= { 8, 2, 512 };
+#define U_MIN 2
static char *lower(char *);
static void read_options(void);
@@ -79,13 +75,10 @@
SLIST_INSERT_HEAD(&opt, op, op_next);
}
- if (maxusers == 0) {
- /* printf("maxusers not specified; will auto-size\n"); */
- } else if (maxusers < users.u_min) {
- printf("minimum of %d maxusers assumed\n", users.u_min);
- maxusers = users.u_min;
- } else if (maxusers > users.u_max)
- printf("warning: maxusers > %d (%d)\n", users.u_max, maxusers);
+ if (maxusers && maxusers < U_MIN) {
+ printf("minimum of %d maxusers assumed\n", U_MIN);
+ maxusers = U_MIN;
+ }
/* Fake MAXUSERS as an option. */
op = (struct opt *)malloc(sizeof(*op));
--
Joseph Koshy <[EMAIL PROTECTED]>
Developer, The FreeBSD Project http://people.freebsd.org/~jkoshy/
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
