Re: Extended error reporting to user space?

[Alan Cox]

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

Thats probably overkill. For almost any ioctl type interface the only
thing you *need* to make more sense is the address of the field that was
deemed invalid.

So in your ioctl handler you'd do something like

	get_user(v, &foo->wombats);
	if (v < 5) {
		error_addr(&oo->wombats);
		return -EINVAL;
	}

returning text is all very well, and printk can help debug, but neither
actually help application code or particularly help interpreters to dig
into the detail and act themselves to fix a problem or understand it. It
also costs material amounts of unswappable memory and also disk storage
for the kernel image on embedded devices.

Two other problems text returns bring up or ambiguity and translations -
its almost impossible to keep them unique even within a big module. It's
also possible to get things like typos in the returned text or
mis-spellings that you then can't fix because some other app now has

	if (strcmp(returned_err, "No such wombat evalueted")==0) {
		...
	}

in it. (HTTP 'referer' being a dark warning from history ...)

A lot of other systems keep message catalogues often indexed by
module:error. Text lookups in userspace (easy to do with existing
interfaces), and the OS providing generic, specific, and identifying
module info.

I guess the Linux extension to that would end up as

	extended_error(&foo->wombats, E_NOT_A_VALID_BREEDING_POPULATION);

and internally expand to include THIS_MODULE and extract the module name.

There's another related problem here too - Unix style errors lack the
ability of some OS systems to report "It worked but ....." which leads to
interface oddities like termios where it reports "Ok" but you have to
inpsect the returned structure to see if you got what you requested.

Doesn't look too hard to add some of this or something similar as you
suggest and while it would take a long time to get coverage you have to
start somewhere.

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