From owner-freebsd-current Tue Oct 17 15:42:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA11847 for current-outgoing; Tue, 17 Oct 1995 15:42:15 -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 PAA11832 ; Tue, 17 Oct 1995 15:42:05 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA28761; Tue, 17 Oct 1995 15:35:22 -0700 From: Terry Lambert Message-Id: <199510172235.PAA28761@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Tue, 17 Oct 1995 15:35:22 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510171851.LAA28198@netcom23.netcom.com> from "Bakul Shah" at Oct 17, 95 11:51:24 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: 2984 Sender: owner-current@FreeBSD.org Precedence: bulk > > 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?:-) 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. > > /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. ??? 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? I can't. Programs that "don't bother" will get the FD_SETSIZE limit or get an error from the kernel, or more likely, corrupt whatever data lives right after where the fd_set lives and eventually mysteriously fail. Checking the limit isn't optional. Reacting to a discrepancy between the user and kernel limits (ie: handling error returns from select) is also not optional. Setting the limit: that's optionalm both in the kernel and in user space. > > meaning you can option it higher in the kernel and you can #define it > > higher before including . > > 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. I don't see how you prevent the kernel from twiddling user bits that follow the fd_set declaration area in the processes address space (or getting a SEGV if it's the last item in the data segment) as a result of shoving down a number that wasn't guarded based on the user's FD_SETSIZE. This seems to be a recipe for bizarre and undetectable data corruption. > 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. If we change the macro names, that means source changes for the people doing the porting, and that won't go over well. The problem occurs in large service sites. And the problem is related to the kernel not knowing how big the user FD_SETSIZE is at select call time. I don't see that going away without an interface change. > Fair enough. So just do > #define __inline__ /*inline*/ > :-) #define __inline__ static ? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.