Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Oct 1995 17:04:23 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        bakul@netcom.com, terry@lambert.org
Cc:        bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org
Subject:   Re: getdtablesize() broken?
Message-ID:  <199510180704.RAA16305@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510180704.RAA16305>