Date: Tue, 11 Apr 2000 10:41:18 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Terry Lambert <tlambert@primenet.com> Cc: arch@freebsd.org Subject: Re: BUF/BIO roadmap. Message-ID: <Pine.BSF.4.05.10004111036550.60516-100000@semuta.feral.com> In-Reply-To: <200004111716.KAA18415@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10004111036550.60516-100000>