From owner-freebsd-questions Thu Jun 20 18:14:54 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA02139 for questions-outgoing; Thu, 20 Jun 1996 18:14:54 -0700 (PDT) Received: from jraynard.demon.co.uk (jraynard.demon.co.uk [158.152.42.77]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA02098; Thu, 20 Jun 1996 18:14:21 -0700 (PDT) Received: (from fqueries@localhost) by jraynard.demon.co.uk (8.7.5/8.6.12) id AAA05791; Fri, 21 Jun 1996 00:34:52 GMT Date: Fri, 21 Jun 1996 00:34:52 GMT Message-Id: <199606210034.AAA05791@jraynard.demon.co.uk> From: James Raynard To: gpalmer@freebsd.org CC: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org In-reply-to: <7073.835304030@palmer.demon.co.uk> (message from Gary Palmer on Thu, 20 Jun 1996 21:53:50 +0100) Subject: Re: Max first parameter of a Select call? Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Note Cc: line changed - this should probably move to -hackers] > > However, is a copy of the types.h used in compiling the > > kernel, which is where the kernel picks up its value of FD_SETSIZE > > from. So a user program can never safely use FD_SETSIZE > 256 without > > a kernel re-compile first! > > It can actually, you get get an error back if you try to set the > number of FD's you want to scan (the `nfds' parameter) to be greater > than the value of FD_SETSIZE when the kernel was compiled (at least, > that's how -stable works, and from a quick glance -current seems the > same). Yep, that's what I said - 256 is the value of FD_SETSIZE that's compiled into the kernel by default. So you have to re-compile the kernel if you want a higher value. 8-) > The real answer is to make it dynamic and dependant on a read-only > sysctl variable or something ... Yes! (The real problem being that there's too much information compiled statically into the kernel here). > I'm not sure if the bitmap's required by the code will be that > forgiving tho :-( I don't see why this should cause problems for the internals of select() - can't ibits and obits be dynamically allocated, based on our sysctl variable, and the rest of the code altered to accommodate? There's a definite problem with FD_ZERO() and friends though, as they depend on FD_SETSIZE through NFDBITS. Actually, we could probably get them to reference the sysctl variable as well, though we might need to re-write them as functions instead of macros... -- James Raynard, Edinburgh, Scotland james@jraynard.demon.co.uk