From owner-freebsd-hackers Mon Jun 28 0:19: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C33FE150EF for ; Mon, 28 Jun 1999 00:19:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA18001; Mon, 28 Jun 1999 00:19:01 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 00:19:01 -0700 (PDT) From: Matthew Dillon Message-Id: <199906280719.AAA18001@apollo.backplane.com> To: Julian Elischer Cc: Warner Losh , hackers@FreeBSD.ORG Subject: Re: "restricted" kernel threads implementation from NetBSD via newconfig References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :please yes.. :eventually we'll be using it to fire off a thread for every interrupt :source if we go the BSDI way. (as dicussed with various people at USENIX) : :I was actually thinking about this today... : :now this is threads within the kernel, and not kernel support for user :threads right? : :julian I think we desparately need a kernel threads implementation. *Any* implementation, so we can start messing around with it! Even if it isn't the one we eventually choose. Once we have something we can add interrupt-thread support to it and then move some of the more innocuous interrupt-based device drivers over to it to generate test cases for the various SMP mechanisms people have been discussing. I was thinking, specifically, of moving a few of the ethernet devices, which tend to have relatively simplistic interrupt-level code - a perfect test case for us because it will be fairly easy to port and fairly easy to measure performance under load. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message