Date: Mon, 20 Sep 1999 12:01:53 +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: <19990920120152.K55065@freebie.lemis.com> In-Reply-To: <Pine.BSF.4.05.9909191332050.42316-100000@semuta.feral.com>; from Matt Jacob on Sun, Sep 19, 1999 at 01:47:31PM -0700 References: <18167.937773025@critter.freebsd.dk> <Pine.BSF.4.05.9909191332050.42316-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 19 September 1999 at 13:47:31 -0700, Matt Jacob wrote: > > >> In message <Pine.BSF.4.05.9909191318570.42254-100000@semuta.feral.com>, Matthew >> Jacob writes: >> >>>> Anyway, David (and Kirk through him) has already said their piece, and >>>> still nobody has named an actual application which depends on bdevs >>>> soo... >>> >>> Isn't that reasoning in reverse? Wouldn't be fairer to state "the problems >>> that we have in the rest of the system are so large because we allow block >>> device access to user programs that we must kill off such access?". >> >> In an ideal world yes. I think the fully expanded version sounds like >> this: >> >> " >> Since having two kinds of access to the device confuses people >> used to Linux > > So to market differentiate FreeBSD from Linux (which is block device only, > finally thinking about adding raw) we go for raw-only? :-) We also show that we're aiming at Linux, and not UNIX. >> and >> Since bdevs gives rise to a complications with buffer/caching > > Fixed in a unified VM/Buffer Cache... As System V does. >> and >> Since having two interfaces forces us to have two majors for >> each device-driver > > I view this as a relatively small problem- either get a larger major > space, or devote a minor bit to distinguish, or go the way solaris goes > and have the same for both: > > bird > pwd > /dev/dsk > bird > ls -Ll c0t1d0s0 ../rdsk/c0t1d0s0 > crw-r----- 1 root sys 32, 8 Jan 23 1998 ../rdsk/c0t1d0s0 > brw-r----- 1 root sys 32, 8 Jan 23 1998 c0t1d0s0 > bird > ls -l c0t1d0s0 ../rdsk/c0t1d0s0 > lrwxrwxrwx 1 root root 77 Jan 23 1998 ../rdsk/c0t1d0s0 -> > ../../devices/io-unit@f,e0200000/sbi@0,0/dma@0,81000/esp@0,80000/sd@1,0:a,raw > lrwxrwxrwx 1 root root 73 Jan 23 1998 c0t1d0s0 -> > ../../devices/io-unit@f,e0200000/sbi@0,0/dma@0,81000/esp@0,80000/sd@1,0:a > bird > grep '^sd' /etc/name_to_major > sd 32 > > [ Yeah, yeah, upgrade issues, yadda yadda yadda yadda ] Right, there's no force in having two majors, it's just the way BSD does it. >> 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? >> 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. >> Sounds like the preamble to a V.FOO standard from CCITT... > > Fair enough. I'll bow out of the discussion now. I believe that there's a > reason to *not* kill bdevs because the problems can and should be solved > other ways. The reason to *keep* access is to keep FreeBSD/Unix with > reasonable, if ancient, capabilities that other Unix systems have, is to > recognize our lack of omniscience. But I've said my piece.. thanks... Agreed. I have a great deal of respect for David and Kirk, but David didn't state the constraints under which they decided bdevs should go away. Poul-Henning did, but I don't buy them. 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?19990920120152.K55065>