On Tue, 15 Jun 1999 21:09:35 -0700  Chuck Silvers wrote:

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

This idea makes me uneasy, as it makes application debugging harder.

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

Yes ... if you have the syslog data, and if you know what time the
failing application ran.  Both to be expected if you're doing the
debugging, but potentially difficult when someone presents you trace
output and says "why does this give EFAULT?".

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

It would need to be a measurable performance benefit to outweigh the
apparent strangeness of EIO appearing as EFAULT, IMHO.

Regards,

Giles