Re: 2.4.0 + iproute2

[Andi Kleen]

On Sun, Jan 14, 2001 at 01:13:16PM +0100, Igmar Palsenberg wrote:
> On Sun, 14 Jan 2001, Andi Kleen wrote:
> 
> > On Sun, Jan 14, 2001 at 03:36:55AM -0800, David S. Miller wrote:
> > >
> > > Andi Kleen writes:
> > >  > How would you pass the extended errors? As strings or as to be
> > >  > defined new numbers? I would prefer strings, because the number
> > >  > namespace could turn out to be as nasty to maintain as the current
> > >  > sysctl one.
> > >
> > > Textual error messages for system calls never belong in the kernel.
> > > Put it in glibc or wherever.
> >
> > This just means that a table needs to be kept in sync between glibc and
> > netlink, and if someone e.g. gets a new CBQ module he would need to update
> > glibc. It's also bad for maintainers, because patches for tables of number
> > tend to always reject ;)
> 
> Agree, but textual strings are bad. I want to say :
> 
> if (error) {
> 	perror("RTNETLINK");
> 	return -1;
> 	}
> 
> Using textual strings means you can't use standard functions. An option
> would be to extend the call so that if the userspace app wants to know
> what really went wrong he can ask the kernel.

That will not work. Consider an application that has multiple rtnetlink
sockets open, which each have own errors.

rtnetlink is such a radical interface for unix, adding a few more changes
for a different error reporting system probably does not make much difference.

my problem with keeping the textual error messages out of kernel is that
it means that three entities (kernel module, number table in kernel and 
external string table) need to be kept in sync. In practice that's usually
not the case.

David's /proc/errno_strings would only require keeping kernel table and
module in sync. 
Text errors for rtnetlink would localize it to the module itself. 
I could probably live with David's solution, although I would prefer the full
way. 

-Andi