[lkml]   [2001]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.0 + iproute2

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.059 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site