Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761510AbXE3WM4 (ORCPT ); Wed, 30 May 2007 18:12:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758654AbXE3WMp (ORCPT ); Wed, 30 May 2007 18:12:45 -0400 Received: from gw1.cosmosbay.com ([86.65.150.130]:35499 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761444AbXE3WMo (ORCPT ); Wed, 30 May 2007 18:12:44 -0400 Message-ID: <465DF627.9090105@cosmosbay.com> Date: Thu, 31 May 2007 00:09:43 +0200 From: Eric Dumazet User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Davide Libenzi CC: Linus Torvalds , Ulrich Drepper , Ingo Molnar , Jeff Garzik , Zach Brown , Linux Kernel Mailing List , Arjan van de Ven , Christoph Hellwig , Andrew Morton , Alan Cox , Evgeniy Polyakov , "David S. Miller" , Suparna Bhattacharya , Jens Axboe , Thomas Gleixner Subject: Re: Syslets, Threadlets, generic AIO support, v6 References: <20070529212718.GH7875@mami.zabbo.net> <465CA654.5000505@garzik.org> <20070530072055.GA3077@elte.hu> <465D286E.2080807@redhat.com> <20070530084252.GA15708@elte.hu> <465DE992.6070803@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [86.65.150.130]); Thu, 31 May 2007 00:09:50 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1342 Lines: 31 Davide Libenzi a ?crit : > On Wed, 30 May 2007, Linus Torvalds wrote: > >>> And then the semantics: do these descriptors should show up in >>> /proc/self/fd? Are there separate directories for each namespace? Do >>> they count against the rlimit? >> Oh, absolutely. The'd be real fd's in every way. People could use them >> 100% equivalently (and concurrently) with the traditional ones. The whole, >> and the _only_ point, would be that it breaks the legacy guarantees of a >> dense fd space. >> >> Most apps don't actually *need* that dense fd space in any case. But by >> defaulting to it, we wouldn't break those (few) apps that actually depend >> on it. > > I agree. What would be a good interface to allocate fds in such area? We > don't want to replicate syscalls, so maybe a special new dup function? > If the deal is to be able to get faster open()/socket()/pipe()/... calls by not finding the first 0 bit in a huge bitmap, a better way would be to have a flag in struct task, reset to 0 at exec time. A new syscall would say : This process is OK to receive *random* fds. - 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/