public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Nikita V. Youshchenko" <yoush@cs.msu.su>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Extended error reporting to user space?
Date: Wed, 17 Feb 2010 10:58:33 +0100	[thread overview]
Message-ID: <87r5ok5gl2.fsf@basil.nowhere.org> (raw)
In-Reply-To: <201002161520.26700@zigzag.lvk.cs.msu.su> (Nikita V. Youshchenko's message of "Tue, 16 Feb 2010 15:20:26 +0300")

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

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

  parent reply	other threads:[~2010-02-17  9:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16 12:20 Extended error reporting to user space? Nikita V. Youshchenko
2010-02-16 12:23 ` Alexey Dobriyan
2010-02-16 13:17   ` Américo Wang
2010-02-17  9:58 ` Andi Kleen [this message]
2010-02-17 10:16   ` Nikita V. Youshchenko
2010-02-17 10:35     ` Andi Kleen
2010-02-17 19:20       ` Dr. David Alan Gilbert
2010-02-17 20:23         ` Andi Kleen
2010-02-21  0:02           ` Dr. David Alan Gilbert
2010-02-17 10:43     ` Alan Cox
2010-02-17 11:57       ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r5ok5gl2.fsf@basil.nowhere.org \
    --to=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yoush@cs.msu.su \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox