Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 21 Nov 2001 08:11:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 21 Nov 2001 08:11:22 -0500 Received: from smtpzilla1.xs4all.nl ([194.109.127.137]:32264 "EHLO smtpzilla1.xs4all.nl") by vger.kernel.org with ESMTP id ; Wed, 21 Nov 2001 08:11:01 -0500 Date: Wed, 21 Nov 2001 14:10:54 +0100 (CET) From: Roman Zippel X-X-Sender: To: Richard Gooch cc: Subject: Re: [PATCH] devfs v196 available In-Reply-To: <200111201819.fAKIJpp10565@vindaloo.ras.ucalgary.ca> 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 Hi, On Tue, 20 Nov 2001, Richard Gooch wrote: > Delayed events are harmless, since devfs ensures correct ordering. It's not about ordering, timing is currently unpredictable, anything timing sensitive has to be very careful to touch anything in devfs. > After consideration, I've decided to dynamically grow the event buffer > as required, and free up space as it's not needed. You should use a slab cache and acknowledge events as soon as they are finished. Right now all processes are waiting until the devfsd is completely finished and restarted at the same time. This is currently limited by dropping events, with a dynamic event queue this can become a problem. > Since devfsd has to > wait for a module load to complete, it's not a good idea to block > waiting for free space in the event buffer (potential deadlock). What do you mean? bye, Roman - 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/