Re: No human readable message with g_vfs

From: Garrett Cooper <yanegomi_at_gmail.com>
Date: Mon, 3 Jan 2011 09:55:30 -0800
On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napierała <trasz_at_FreeBSD.org> wrote:

> Wiadomość napisana przez Kostik Belousov w dniu 2011-01-03, o godz. 15:18:
>> On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote:
>>> Am 03.01.2011 14:14, schrieb Ivan Voras:
>>>> On 12/29/10 11:32, David Demelier wrote:
>>>>> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel:
>>>>> g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error
>>>>> = 5
>>>>> 
>>>>> I think for a lambda user these are absolutely not understandable. I
>>>> 
>>>> Would a better message be "WRITE error on da0, offset=34590720.
>>>> length=65536, errno=5"?
>>> 
>>> nah, strerror(errno) isn't that much of an effort
>> In kernel ? There is no strerror, and there is no great need to import the
>> sys_errlist.
> 
> I had code that adds strerror() to the kernel in one of my old p4 branches.
> Error messages like the one above look much better this way, but I didn't
> have time to push it into the tree, and there is a risk of yet another i18n
> discussion.  If someone is interested - let me know; I'll try to find it.

Some thoughts:
- It's a pain to parse (before I just had to scan for an int -- now it's a string?!?)
- It slows down printing (slow kernel -> dog slow system).
- Fills up logs quicker if a subsystem or piece of hardware is going south and these messages slam syslog, which means I have to scan more logs looking for useful data, the likelihood of messages being lost in various buffers is higher, etc.

Why not just provide a more standard sensical printout for the messages and provide a secret decoder ring in userland or something for interested parties the don't know that error is an errno value (eg my mom and dad because they're unix illiterate), or just copyout all of the error data via an ioctl, print out the ioctl failures, and skip the kernel level printing altogether?

Thanks!
-Garrett
Received on Mon Jan 03 2011 - 16:55:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:10 UTC