From owner-freebsd-arch Mon May 15 9:55:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 3532637BB1B; Mon, 15 May 2000 09:55:10 -0700 (PDT) (envelope-from n_hibma@calcaphon.com) Received: from calcaphon.demon.co.uk ([193.237.19.5] helo=bluebottle.qubesoft.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12rO8r-000DtV-0A; Mon, 15 May 2000 16:54:53 +0000 Received: from henny.webweaving.org (henny.qubesoft.com [192.168.1.5]) by bluebottle.qubesoft.com (8.9.3/8.9.1) with ESMTP id RAA38632; Mon, 15 May 2000 17:54:49 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id LAA82369; Mon, 15 May 2000 11:20:32 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Date: Mon, 15 May 2000 11:20:32 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Mike Smith Cc: Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005141948.MAA09452@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We have a number of different callout list implementation kicking around > in the kernel at the moment; > > - the EVENTHANDLER stuff > - the optimised callout list handling in kern_timeout.c > - a few ad-hoc leftovers like config_intrhook that should have been > EVENTHANDLERed but weren't - The delayed attach for disk devices - The after interrupts-have-been-switched-on task queue None of these need any functionality above the provided stuff. > - The ability to search for a taskqueue by name (I really don't like the > hard binding that's required by having the linker do this). Good idea. This can easily be implemented on what is there now. (struct taskqueue *) taskqueue_find(const char *name) > - Some more flexibility in the enqueueing of tasks, particularly the > ability to specify a priority so that tasks on the queue are executed > in an ordered fashion. It would be useful in the case of attachment of drives (giving priority to the fixed controllers over for example the USB ones (USB Zip drives not stealing the da0 entry when attached without wiring things down, John Baldwin reported this one). > - Static taskqueue initialisers. > > None of these are particularly heavyweight, and they'll all end up > *reducing* bloat and complexity. I agree. Doing it right the first time. Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message