From owner-freebsd-hackers  Tue Oct 17 11:03:05 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id LAA02017
          for hackers-outgoing; Tue, 17 Oct 1995 11:03:05 -0700
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02012
          ; Tue, 17 Oct 1995 11:03:02 -0700
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA27890; Tue, 17 Oct 1995 10:55:49 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199510171755.KAA27890@phaeton.artisoft.com>
Subject: Re: getdtablesize() broken?
To: bakul@netcom.com (Bakul Shah)
Date: Tue, 17 Oct 1995 10:55:49 -0700 (MST)
Cc: bde@zeta.org.au, terry@lambert.org, current@freefall.freebsd.org,
        hackers@freefall.freebsd.org
In-Reply-To: <199510171028.DAA04795@netcom5.netcom.com> from "Bakul Shah" at Oct 17, 95 03:28:53 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2286      
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

> 
> > 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.