Extended error reporting to user space?
in [Kernel]
|
Prev: (none)
Next: Itanium support ...
From: Nikita V. Youshchenko on 16 Feb 2010 07:30 Hi 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. Nikita -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexey Dobriyan on 16 Feb 2010 07:30 On Tue, Feb 16, 2010 at 2:20 PM, Nikita V. Youshchenko <yoush(a)cs.msu.su> wrote: > Unfortunately this -EINVAL is not really useful. There is no such thing. Driver can spit messages with printk() though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Américo Wang on 16 Feb 2010 08:20 On Tue, Feb 16, 2010 at 02:23:55PM +0200, Alexey Dobriyan wrote: >On Tue, Feb 16, 2010 at 2:20 PM, Nikita V. Youshchenko <yoush(a)cs.msu.su> wrote: >> Unfortunately this -EINVAL is not really useful. > >There is no such thing. >Driver can spit messages with printk() though. Right, if errno is not enough, printk() is. You could also use other interface to debug, but printk() is the simplest. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 17 Feb 2010 05:00 "Nikita V. Youshchenko" <yoush(a)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. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nikita V. Youshchenko on 17 Feb 2010 05:20
> "Nikita V. Youshchenko" <yoush(a)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? 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |