Re: 2.4.0 + iproute2

[Igmar Palsenberg]

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

errno is only valid until a new syscall is done. So I don't see the
problem with multiple sockets, you can only perform one at a time.

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

I wonder if the glibc keeps it's own copy of the sys_errlist[]. If it has,
that means that we indeed have a problem..
Maybe the kernel could provide errno -> textual mapping, but that sounds
like bloat to me..

An other way is to have some kind of extended error.

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

Disadvantage of textual stuff is that you can't do more then print it. 

> -Andi

	Igmar