From owner-cvs-all Sun Sep 19 20:56:26 1999 Delivered-To: cvs-all@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 9934F14CC5; Sun, 19 Sep 1999 20:56:19 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA07788; Mon, 20 Sep 1999 13:25:49 +0930 (CST) Date: Mon, 20 Sep 1999 13:25:49 +0930 From: Greg Lehey To: Matthew Jacob 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) Message-ID: <19990920132549.O55065@freebie.lemis.com> References: <19990920120152.K55065@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Matt Jacob on Sun, Sep 19, 1999 at 08:10:52PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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