Joseph Malicki wrote:
>
> It's an issue when it MIGHT be important. Such as, fprintf to an important
> data file should be checked, fprintf to stderr is usually cool not to check.
That's an application issue. From the kernel point of view, we cannot
tell
which errors matter to the application, so we just return error on any
we
can detect and let the app worry about it.
> People are going on the assumption that ignoring an error to a system call
> will interfere with program operation or corrupt data - which is NOT
> necessarily true. Sure many people write programs that way. But it is
> quite often that if something fails, you don't particularly care, and you
> know, with certainty, that it does not materially affect the operation of
> your program. For instance, should shutdown fail just because it couldn't
> write a message to everyone's console?
Again, that's an application issue; shutdown should succeed no matter
what
files or devices become inaccessible, so it should be written to
continue
despite error codes, likely with a console message about the error.
>From the kernel point of view, the only question is whether to return an
error when it cannot write where it is asked to. Of course it must.
I don't see why anyone is bothering to argue on the kernel list about
what applications should do with error returns. That's not our problem.
All we need to worry about is:
what errors are possible,
whether they can be detected
whether any merit a panic or kernel logging
what to return to the application in each case
If the kernel gets those right, it has done its part.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:34 EST