Re: No human readable message with g_vfs

Garrett Cooper <yanegomi_at_gmail.com> writes:

> 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

Do you mean perror(1)?

  $ perror 5
  Input/output error

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