From owner-freebsd-hackers  Wed Oct 18 00:08:29 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id AAA02108
          for hackers-outgoing; Wed, 18 Oct 1995 00:08:29 -0700
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 AAA02101
          ; Wed, 18 Oct 1995 00:08:22 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA16305; Wed, 18 Oct 1995 17:04:23 +1000
Date: Wed, 18 Oct 1995 17:04:23 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510180704.RAA16305@godzilla.zeta.org.au>
To: bakul@netcom.com, terry@lambert.org
Subject: Re: getdtablesize() broken?
Cc: bde@zeta.org.au, current@freefall.freebsd.org,
        hackers@freefall.freebsd.org
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>> > I don't see where this massive amount of runtime work is really worth it.
>> 
>> It is not massive amount of runtime work.  Changes are
>> fairly straight forward.  The runtime cost is small.
>> ...

>Basically, all of the user space code that uses the standard-since-4.2
>sys/types.h definitions would need to be rewritten.  This is what I
>meant.

The select() interface has pointers to fd_set's, so it doesn't rule out
using arrays of fd_set's.  I think only the FD_ macros and the
documentation would need to be rewritten.

>> This is well and good for *user* programs.  Most programs don't
>> want to bother with changing FD_SETSIZE and kernel changes
>> I am proposing are transparent to such programs.

>???

>How do I make a program which doesn't guard using FD_SETSIZE the max fd
>it tries to select upon suddenly have a larger statically or stack
>declared bitvector array?

Don't use the standard FD_ macros.

Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for
compatibility.  There is no reason why the Linux FD_SETSIZE should be as
limited as the FD_SETSIZE that the kernel happened to be compiled with.
Fixed limits defeat binary compatibility.  This is particularly annoying
for fixed limits like OPEN_MAX that aren't actually fixed even on the
host OS.  See <sys/syslimits.h> for a long list of bogus limits.

Bruce