Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 18 Jun 2002 16:41:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 18 Jun 2002 16:40:59 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:56328 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Tue, 18 Jun 2002 16:40:57 -0400 Date: Tue, 18 Jun 2002 13:41:12 -0700 (PDT) From: Linus Torvalds To: Rusty Russell cc: Robert Love , Linux Kernel Mailing List Subject: Re: latest linus-2.5 BK broken In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1245 Lines: 39 On Wed, 19 Jun 2002, Rusty Russell wrote: > > So any program that doesn't use the following is broken: That wasn't so hard, was it? Besides, we've had this interface for about 15 years, and it's called "select()". It scales fine to thousands of descriptors, and we're talking about something that is a hell of a lot less timing-critical than select ever was. "Earth to Rusty, come in Rusty.." How do we handle the bitmaps in select()? Right. We assume some size that is plenty good enough. Come back to me when something simple like #define MAX_CPUNR 1024 unsigned long cpumask[MAX_CPUNR / BITS_PER_LONG]; doesn't work. The existing interface is _fine_, and when somebody actually has a machine with more than 1024 CPU's (yeah, right, I'm really worried), the existing interface will cause graceful errors instead of doing something unexpected. And if you're telling me that people who care about CPU affinity cannot fathom a simple bitmap of longs, you're just out to lunch. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/