Date: Tue, 11 Apr 2000 17:16:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mjacob@feral.com Cc: tlambert@primenet.com (Terry Lambert), arch@freebsd.org Subject: Re: BUF/BIO roadmap. Message-ID: <200004111716.KAA18415@usr01.primenet.com> In-Reply-To: <Pine.BSF.4.05.10004110952590.60516-100000@semuta.feral.com> from "Matthew Jacob" at Apr 11, 2000 09:59:00 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > It also seems to me that kernel threads are _still_ a significantly > > bad idea, since the problems faced in kernel preemption are a subset > > of the problems faced in Real Time support, and that as a result, it > > will be significantly harder to support Hard Real Time in the future > > without significant revisions of the the OS architecture. > > 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. > 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, and damages the ability to make deterministic guarantees about the amount of time a given driver task will take to complete. Being error conditions, this is probably acceptable, since one really can't expect a system to exhibit deterministic behaviour while it is experiencing hardware failures. > The existing CAM subsystem would be a *lot* easier to follow/debug > if it were threads/proc based. I think that if it were formally documented using UML, it would not only be easier to follow and do things like bring in the drivers which fell by the wayside when it was first innaugarated, debugging would be significantly easier than if it had threads. 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. > From a political point of view it's important as well. Veritas > points out to me that they'll be porting VxFS and other products > to Linux long before they'd port it to FreeBSD because Linux > (like Solaris, NT, HP/UX) have a kernel threads model. You may > be right with what you assert- I won't attempt to involve myself > at that level, but from the point of view of this platform > succeeding, well, I believe you're lifting at the heavy end, my > friend. 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200004111716.KAA18415>