Date: Sun, 19 Sep 1999 21:53:56 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Greg Lehey <grog@lemis.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: <Pine.BSF.4.05.9909192147130.43049-100000@semuta.feral.com> In-Reply-To: <19990920132549.O55065@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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. Linux is as close to some versions of Unix that I'd still call it 'U*ix'. Internally it's a very different fish. Some things better, some not. But not really any wilder than others (I remember looking at some DG-UX documents and they'd changed a block device's strategy routine to be "async_IO_entry_point" or some such). If it weren't, my Qlogic ISP driver wouldn't be the 75%+ common code for the Linux version vs. the FreeBSD or NetBSD or OpenBSD versions. > > 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. uh...........I can see some interesting debugging ahead... > > >>>> 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. Possibly they're waiting for some of the small fry to get exhausted and go away so they can resume what they were doing about it? :-) 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.9909192147130.43049-100000>