Re: Extended error reporting to user space?

[Nikita V. Youshchenko]

> "Nikita V. Youshchenko" <yoush@xxxxxxxxx> 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?

For example, have a "last error" string associated with task_struct, that:
- will clean on each syscall entry,
- while syscall is running, may be filled with printf-style routines,
- may be accessible from userspace with additional syscall [that obviously 
should not reset error]?

This will give driver writers a common interface for extended error 
reporting...

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