Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Sep 1999 20:10:52 -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.9909192005170.42915-100000@semuta.feral.com>
In-Reply-To: <19990920120152.K55065@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...

> ..
> >>     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.



> 
> >>     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.  I have a great deal of respect for David and Kirk, but David

Me too.



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.9909192005170.42915-100000>