From owner-cvs-all Sun Sep 19 20:11:15 1999 Delivered-To: cvs-all@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 34C0C1527F; Sun, 19 Sep 1999 20:11:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id UAA01009; Sun, 19 Sep 1999 20:09:17 -0700 Date: Sun, 19 Sep 1999 20:10:52 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: Poul-Henning Kamp , Matthew Dillon , dg@root.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: User block device access (was: cvs commit: src/sys/miscfs/specfs spec_vnops.c src/sys/sys vnode.h src/sys/kern vfs_subr.c) In-Reply-To: <19990920120152.K55065@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > We also show that we're aiming at Linux, and not UNIX. Bad move in my opinion, but that's another thread... > .. > >> and > >> Since bdevs have not been returning write errors for 5+ years > > > > I don't believe that this is necessarily as bad as you make it out to > > because close(2) can (and should) return any collected errors (as it > > should also do for the close of a file in a filesystem :-)). > > Also, a lot of the I/O is VM paging. How do you want to return an > error there? If not via a system call like read, close, which can return an errno, e.g., via a mapped segment, then: psignal(b->b_proc->p_pid, SIGSEGV); perhaps with the extended fault codes that indicate an underlying I/O error. > > >> and > >> Since most of the original reasons for having bdevs have gone > >> away > > We no longer need buffering? I don't understand what you're saying > here. That's Poul's statement, not mine. > .. > Agreed. I have a great deal of respect for David and Kirk, but David Me too. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message