Date: Mon, 20 Sep 1999 13:25:49 +0930 From: Greg Lehey <grog@lemis.com> To: Matthew Jacob <mjacob@feral.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Matthew Dillon <dillon@apollo.backplane.com>, 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) Message-ID: <19990920132549.O55065@freebie.lemis.com> In-Reply-To: <Pine.BSF.4.05.9909192005170.42915-100000@semuta.feral.com>; from Matt Jacob on Sun, Sep 19, 1999 at 08:10:52PM -0700 References: <19990920120152.K55065@freebie.lemis.com> <Pine.BSF.4.05.9909192005170.42915-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 19 September 1999 at 20:10:52 -0700, Matt Jacob wrote: >> We also show that we're aiming at Linux, and not UNIX. > > Bad move in my opinion, but that's another thread... I'm not sure it's the case: there's enough evidence that we're ignoring Linux. I'd really like to retain the UNIX look and feel, though, until we have damn good reasons not to do so. >>>> 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. Seems reasonable. We could use a similar method to return write I/O errors. [sees whole new thread starting]. The Linux people are talking about queued signals as a way for sending information to a process. >>>> 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. It seems to me that this question hasn't been discussed enough. Buffering is one of the biggest performance factors in the system. Nobody's really talking about removing it, just how to do it, and it seems that at least one of the major players hasn't been in the loop. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990920132549.O55065>