Date: Tue, 17 Oct 1995 10:55:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bakul@netcom.com (Bakul Shah) Cc: bde@zeta.org.au, terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510171755.KAA27890@phaeton.artisoft.com> In-Reply-To: <199510171028.DAA04795@netcom5.netcom.com> from "Bakul Shah" at Oct 17, 95 03:28:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > I get 64. Perhaps you have a shell bug.
>
> Possible. Or may be there is an exra fd open. zsh seems to be
> the culprit here.
>
> > >It is this hardwired use of FD_SETSIZE *in* the kernel I am
> > >bitching about.
>
> > The limit is built in to the fd_set type. The FD_SETSIZE check
> > just makes sure that all the bits fit in the kernel fd_set
> > variables. The kernel needs to use dynamically allocated
> > arrays to hold more bits, and different methods to access the
> > bits...
>
> But of course! [My fix was partial but if you decide to
> banish FD_SETSIZE removing all use of fd_set follows -- I
> should never respond when I am half asleep; but that is when
> I get some free time :-(] Anyway, instead of fd_set the
> kernel needs to use just int* (and allocate enough ints).
> Instead of macros FD_{SET,CLR,ISSET,ZERO} it can use
>
> #define SET_BIT(n, p) ((p)[(n)/NFDBITS] |= (1 << ((n) % NFDBITS)))
> #define CLR_BIT(n, p) ((p)[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS)))
> #define ISSET_BIT(n, p) ((p)[(n)/NFDBITS] & (1 << ((n) % NFDBITS)))
> #define ZERO_BITS(n, p) bzero((char*)(p), \
> howmany((n), NFDBITS) * sizeof(fd_mask))
I assume (well, you assume 8-)) the size of the bit vector array type
in the declaration is sizeof(x) == NFDBITS?
This leads to:
#define MAX_BIT(x) (sizeof(x)/NFDBITS)
I don't see where this massive amount of runtime work is really worth it.
/usr/unclude/sys/types.h has the forllowing in it:
#ifndef FD_SETSIZE
#define FD_SETSIZE 256
#endif
meaning you can option it higher in the kernel and you can #define it
higher before including <sys/types.h>.
> [Going off on another tangent -- I wish we can start using
> inline functions instead of such odious macros -- even though
> inline is not ISO sanctioned every compiler worth its salt
> provides it]
It should be an option. But like having C equivalents for asm library
routines or compiler inlines, it needs to be allowed to be turned off.
Most ports do not start out self hosting until quite some way down the
road, and the reason such things are avoided (or replicated) is to
ease porting requirements.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510171755.KAA27890>