"Jason R. Fink" <jrf@adresearch.com> writes:

> > > We could introduce a runtime sysctl-able limit, say 256, for instance,
> > > and return that value?
> 
> this actually seems to be what we (netbsd) would prefer, 
> after reading the sysconf man page.

sysconf(3) doesn't really convey that 'preference'.  However, since
sysctl is the interface the kernel uses to make such values accessible
to userland, and sysconf is a portable interface to access that
particular system limit, it would be the way to go.

Actually, making kern.ngroups writable for that purpose would seem
an intuitive choice of interface to me.  But for the implementation ...

> > Having reread the posix/opengroup spec, it looks as though the
> > 'correct' thing is to #define NGROUPS_MAX to (say) 16 and have
> > sysconf(_SC_NGROUPS_MAX) return -1.
> 
> theorhetically this is doable now, it just has to be 
> implemented.

.. is there really a demand for an 'unlimited' NGROUPS_MAX?  With the
present data structure, even a run-time changeable limit could be
messy to implement.  Wouldn't kernel compile-time be sufficient for
most purposes (possibly combined with bumping the limit)?

Anyway, back to sysconf aspects.

> 2) using sysconf for posix compliance
> 
>                                          for item 2
> well that is sort of a can of worms because there are
> a lot of things that do not route through sysconf
> since sysctl is better.

Do you have something specific in mind, here?  Supporting and using
POSIX variables in sysconf is fine/encouraged/expected, of course, but
adding a sysconf knob for every NetBSD-specific sysctl variable isn't
possible (think of sysconf's signature) nor would enhance
'portability' in any way.


- Klaus