Subject: Re: UBC info
To: Wolfgang Solfrank <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 06/15/1999 21:09:35
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).
Wolfgang Solfrank writes:
> > 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 :-(.)
> ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800