lkml.org 
[lkml]   [2010]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Extended error reporting to user space?
* Andi Kleen (andi@firstfloor.org) wrote:
> On Wed, Feb 17, 2010 at 01:16:48PM +0300, Nikita V. Youshchenko wrote:
> > > "Nikita V. Youshchenko" <yoush@cs.msu.su> writes:
> > > > I'm developing a device driver that, in it's ioctl()s, accepts a
> > > > complex data structure. Before doing it's operation, it performs large
> > > > number of checks if data is valid. If one of those checks fail, driver
> > > > returns -EINVAL.
> > > >
> > > > Unfortunately this -EINVAL is not really useful. E.g. if a developer,
> > > > sitting in his IDE and debugging his code, will see ioctl()
> > > > returning -EINVAL, and will have hard times finding what exactly is
> > > > wrong.
> > > >
> > > > Before inventing driver-specific extended error reporting, I'd like to
> > > > ask if there is anything more or less generic for this.
> > > > I believe situation when -Exxx is too weak interface for error
> > > > reporting is common.
> > >
> > > This is a very common problem in Linux unfortunately. I always
> > > describe that as a the "ed approach to error handling". Instead
> > > of giving a error message you just give ?. Just ? happens
> > > to be EINVAL in Linux.
> > >
> > > My favourite example of this is the configuration of the networking
> > > queueing disciplines, which configure complicated data structures and
> > > algorithms and in many cases have tens of different error conditions
> > > based on the input parameters -- and they all just report EINVAL.
> > >
> > > The standard way (standard kludge or standard workaround would be a
> > > better description) is to use printk; often guarded by a special
> > > kernel tunable or ifdef to avoid flooding the log in the normal case.
> > >
> > > IMHO it would be best to simply add a way to return strings directly
> > > in this case (a la plan9). This would be probably not too hard to
> > > implement. It's not there unfortunately.
> > >
> > > This could be done with one of the message oriented protocols,
> > > e.g. netlink or read/write on a special minor.
> >
> > Why not create a generic solution for this, if one does not exist yet?
>
> Someone would need to do it. Yes I think it would be a worthy project.
>
> The trick is also get around the objections of the "but we always
> did it this way" Unix traditionalists.

I'd wondered about some form of halfway house where the error
value is expanded but could be truncated for compatibility - i.e.
if at the moment we had:

return -EINVAL;

it would become:

return ERRORNUM(EINVAL, BADLENGTH);

and that would expand to something like:
return -(EINVAL + BADLENGTH << ESHIFT);

existing syscall handlers could mask the extended error bits out on the way
back, and a new entry could pass the whole error value back where user space
could separate out the other part of the error.

This still feels quite like stretching the traditional way; but at the cost
of it still having the same problems (e.g. having to define a list of error
values).

One hard problem is that often the thing that actually returns the error
has actually just got a failure from something that called it which didn't
return any diagnostics, so to do this properly errors have to be passed
around in a lot of places; you'll also have to figure out just how far
down you want to pass it - if a read() fails due to a SCSI error there
is a whole load of different levels of information that you have to chose
what to return.

<snip>

Dave (who has stared at mmap's that have returned EINVAL for way too long)

--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/


\
 
 \ /
  Last update: 2010-02-17 20:53    [W:0.068 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site