Date: Sun, 19 Sep 1999 13:47:31 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.com>, dg@root.com, Greg Lehey <grog@lemis.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: <Pine.BSF.4.05.9909191332050.42316-100000@semuta.feral.com> In-Reply-To: <18167.937773025@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? :-) > and > Since bdevs gives rise to a complications with buffer/caching Fixed in a unified VM/Buffer Cache... > 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 ] > 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 :-)). The same issues come up for raw devices too, btw, whenever you do any kind of write caching (typically always on for tapes, very desirably on for disks). > and > Since most of the original reasons for having bdevs have gone > away > and > Since nobody can show real-world applications which rely on > the bdev interface I have no answer for this... > then > We should kill bdevs Aww, let's kill devices as files in general and require access manager ports instead..... :-) > > 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... -matt 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?Pine.BSF.4.05.9909191332050.42316-100000>