From owner-freebsd-arch Tue Apr 11 13:19:10 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 3110237BAEF for ; Tue, 11 Apr 2000 13:19:06 -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 WAA18499 for ; Tue, 11 Apr 2000 22:19:09 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA00195 for freebsd-arch@freebsd.org; Tue, 11 Apr 2000 22:18:58 +0200 (CEST) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0D16E37B796 for ; Tue, 11 Apr 2000 10:41:28 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA24758; Tue, 11 Apr 2000 10:41:12 -0700 Date: Tue, 11 Apr 2000 10:41:18 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: arch@freebsd.org Subject: Re: BUF/BIO roadmap. In-Reply-To: <200004111716.KAA18415@usr01.primenet.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 > > Whether it's threads or additional kernel processes that can be schedule from > > interrupt level, I don't care, but the class of problems this solves for me > > makes it very desirable. > > The problems it appears to me to solve are those problems which > are more difficult to solve using, but more elegantly solved by, > finite state automa. Umm. That's very true. The reality is that nobody funds the amount of time it takes to do true DFAs. > > > The current approach in Linux of creating an interrupt/error handler > > thread per SCSI host adapter is *very* cool with respect to solving > > complex error issues in a clean fashion. > > Errors are exceptional conditions. Handling these in a seperate > thread is inelegant, The term "inelegant" is not a valid arguing point, except for what *you* prefer. I like threads. Fork level processing as implemented under RSX-11 for interrupts (essentially a microthread) is probably some of the most elegant and tight code ever written. > > The existing CAM subsystem would be a *lot* easier to follow/debug > > if it were threads/proc based. >>... > My reasoning for this is that it's possible to construct branch > path validation code from (accurate) UML models, and it is possible > to create formal proofs of code correctness. Point taken. > ... > Having hacked on the VXFS code in UnixWare 2.x at Novell/USG (the > former USL: Hi, Mike and Mike!), I can assure you that the FreeBSD > "kernel process" creation method used to create syncd, swapper, > etc., is more than sufficient to support the VXFS "cleaner" task. > Your Veritas argument is a strawman; they are porting to Linux > because that's where they can get the most press. Yes and no. They do say that 'mindshare' is important. But when I, for instance, argue there to do things under FreeBSD, it's a harder sell w/o a kernel threads model. This isn't probably an 'arch' argument- sorry I brought it up. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message