I was planning on just letting i/o errors return EFAULT to the application.
I can't think of an application that would really care whether a read()
failed because of bogus arguments vs. an i/o error.  either way, the data
doesn't get where it was supposed to go.

you can still tell the difference administratively by virtue of i/o errors
being logged via syslog.  (I don't know if we currently log all i/o errors
or not, but we should.)

does anyone feel it's important to retain EIO returns for real i/o errors
in the filesystem?  there's a performance benefit for letting them turn
into EFAULT (or so the theory goes).

-Chuck


Wolfgang Solfrank writes:
> Hi,
> 
> > so UBC mappings
> > can only be accessed via fault-safe methods like uiomove().
> 
> Do I understand this correctly that the copyin/copyout (which is called
> by uiomove to do the work) has to check the kernel address in addition
> to the user address?  Yes, I know that most implementations will just
> return EFAULT from copyin/copyout on any non-recoverable page fault, but
> I thought this was only implementation laziness.
> 
> In case I understand this correctly, how are you going to return EIO
> to the user in case of an I/O error and distinguish this from a "real"
> EFAULT, given the current copyin/copyout implementations?
> 
> (If this is already taken care of in your implementation, I apologize,
> but at the moment I'm unable to look into the repository :-(.)
> 
> Ciao,
> Wolfgang
> -- 
> ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800