Re: the ridiculously large granularity of "errno" (was Red Hat problem on a cobalt server)

From: Igmar Palsenberg (maillist@chello.nl)
Date: Mon Jun 26 2000 - 08:16:36 EST


> David S. Miller writes the following:
> >
> >The path to the perl binary is wrong on the first line
> >of your hello.pl script.
>
> Obvious, wasn't it? You could also guess that the first line of the hello.pl
> script is #!/usr/bin/perl^M and have a pretty good chance of being right.
>
> But why should people like the original poster have to suffer with vague
> (some might even say incorrect) error messages like that? The kernel does a
> lousy job of reporting errors, because there aren't enough errno values to go
> around. If an exec returns ENOENT, what didn't exist? The filename that was
> passed in? Sometimes... other times it means the script interpreter didn't
> exist, other times it means the ELF interpreter ld-linux.so.* didn't exist.
>
> The kernel chooses to throw such details away and return a generic errno
> value, and the user must investigate each of the possible errors that can be
> represented by that errno, to figure out which error actually occurred.
>
> There are 132 lines in my asm/errno.h. Can anyone seriously believe that 132
> (minus #if/#endif and blank lines in that file) error messages are enough to
> adequately explain everything that can go wrong in a syscall? Oh yes, and
> lots of them are not even used anywhere. EBFONT?
>
> Why not EINTERPNOENT for execve? And for rename, ESRCNOENT and EDSTNOENT. And
> quotactl returning ESRCH will never make sense as long as strerror(ESRCH) is
> "No such process". It needs a new errno meaning "No quota entry"

NOQUOTA is a valid error.
 
> I anticipate this response:
>
> If we add new errnos whenever there's a new error that doesn't fit one of
> the existing ones, libc will never be able to keep up!
>
> To which I say int sys_strerror(int,char*,size_t). "But what about i18n" you
> ask? I'd rather have a correct error message that I don't understand than one
> which I understand but is a lie.

It isn't lying. It's been this way for ages, and it's number one in every
CGI FAQ I've ever seen.

        Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:09 EST