From owner-freebsd-arch Tue Apr 11 13:11:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D58437B9F0 for ; Tue, 11 Apr 2000 13:11:42 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA18438 for ; Tue, 11 Apr 2000 22:11:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA00395 for freebsd-arch@freebsd.org; Tue, 11 Apr 2000 22:11:32 +0200 (CEST) Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 4147437BB8F; Tue, 11 Apr 2000 10:14:59 -0700 (PDT) (envelope-from julian@elischer.org) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id BAA13180; Wed, 12 Apr 2000 01:14:57 +0800 Received: from jules.elischer.org (reggae-11-63.nv.iinet.net.au [203.59.69.63]) by muzak.iinet.net.au (8.8.5/8.8.5) with SMTP id BAA29526; Wed, 12 Apr 2000 01:14:56 +0800 Message-ID: <38F35C84.2F1CF0FB@elischer.org> Date: Tue, 11 Apr 2000 10:10:28 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Kirk McKusick Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: BUF/BIO roadmap. References: <200004110225.TAA26536@flamingo.McKusick.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kirk McKusick wrote: > > It is my understanding that the BSD/OS MP work will soon be > considered for incorporation into FreeBSD. Part of that > project will include the addition of interrupt threads. > Assuming that they go in, it will not be necessary to have > a devd process. Beyond that, I agree with Julians comments. > > Kirk I posit that an in kernel devd might be a good abstraction, even in the case of having blockable interrupts. It is possible that the device that reports a new arrival, may want to generate more interrupts (a 2nd drive on a scsi chain may be active) and not be held up waiting for probing of the ist drive to complete. While having blockable interrupts would make the probing provably safe, it may not have the characteristics we want. There are other tasks that such a daemon can do, for example, poll the floppy for media removal. (which can be done on PCs without starting the motor). -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message