Date: Tue, 17 Oct 95 11:51:24 -0700 From: Bakul Shah <bakul@netcom.com> To: Terry Lambert <terry@lambert.org> Cc: bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510171851.LAA28198@netcom23.netcom.com> In-Reply-To: Your message of "Tue, 17 Oct 95 10:55:49 PDT." <199510171755.KAA27890@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I assume (well, you assume 8-)) the size of the bit vector array type
> in the declaration is sizeof(x) == NFDBITS?
No. NFDBITS == sizeof (fd_mask) * 8. Type fd_mask is
defined to be long. As far as the kernel is concerned,
select() args that are bit vector arrays, are *large* enough
to hold nfds number of descriptors, where nfds is the first
arg to select(). The (uap->nd <= p->p_fd->fd_nfiles) check
bounds this number to something sensible.
> 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.
It is worth it to me. But a more general argument is that
without this fix file descriptors > FD_SETSIZE are second
class citizens. You _are_ a fan of consistency, are you?:-)
> /usr/unclude/sys/types.h has the forllowing in it:
> #ifndef FD_SETSIZE
> #define FD_SETSIZE 256
> #endif
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.
> meaning you can option it higher in the kernel and you can #define it
> higher before including <sys/types.h>.
This is not a good option for commercial software.
Customers generally don't like to rebuild the kernel for
such things. So I am forced to use the more complex
solution.
It is difficult enough to convince companies to support
{Net,Free}BSD -- unfortunately a lot more difficult than
Linux (which is wildly more popular inspite of its growing
pains) -- and this sort of scaling problems makes it harder
-- especially when Solaris, IRIX etc. already do them right.
> 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.
Fair enough. So just do
#define __inline__ /*inline*/
:-)
--bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510171851.LAA28198>