No human readable message with g_vfs

[Garrett Cooper]

On Jan 3, 2011, at 10:20 AM, Anonymous wrote:

> 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

Heh -- didn't realize that someone made a userland app for that libcall already :D... You learn new things everyday I guess :).

In that case IMO nothing needs to be done minus (if you're interested) creating a parser that data mines stuff to make it more human readable in a common format, i.e.

error: 5 (Input/output error)
<subsystem specific information does here>

that would make life when reporting PRs or issues on the list a lot more uniform and easier to follow, and could apply to several utilities (atacontrol, camcontrol, etc). My company has a similar in-house tool that does that, but it's not necessarily the easiest tool to deal with nor the most correct when it comes to some issues in FreeBSD.

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