Subject: Re: More verbose SCSI errors...
To: None <email@example.com>
From: Matthew Jacob <firstname.lastname@example.org>
Date: 08/19/1997 08:30:03
>On BSDI the driver logged the sense key and ASC/ASCQ in numeric form.
>They also have a program that converts and ASC/ASCQ code
>into the corresponding text.
>This approach seems to be more general to me than having the kernel
>spit out out the text messages. But then, it is probably less confusing
>for the users if the kernel does the translation.
Hmm. I sorta like this approach as it keeps kernel bloat from happening,
is easier to change, etc.. I did something similar for Legato where all
the strings (and all the SCSI command processing, mode sense encode/decode,
jukebox commands) were all in a shared user library.. it has real advantages..
Unfortunately, it isn't always possible run a the user daemon that can
decode the error messages enough to distinguish, for a wildass example,
'media error, asc/ascq=0x30/0x00' from 'media error, asc/ascq=0x11/0x01',
on a read/write optical you're booting off of...(the former asc/ascq is
'incompatible medium installed' indicating you grabbed the wrong cartridge
to insert and the latter is 'read retries exhausted' meaning that this
platter is toast).
What you suggest though, does raise a tough call question. I really
am torn between taking the BSDI approach (requiring more userland work,
but that's okay) and getting instant functionality.
I think that I lean toward getting the functionality now, and then mentioning
to the user community that because Unix never came with an embedded error
logging && diagnostic functions, and it seems to have always taken real
(and somewhat boring) companies like DEC or IBM (or even Unisys) to add real
standalone and runtime hardware diagnostics, that it would be real nice
if someone thought about this as a true added value to NetBSD (and other
base Unix systems)- and I mean *embedded* functionality that will probably
touch all drivers and require a serious infrastructure, including enclosure
and environmental services, tie in with SNMP, go boldly where no BSD
derived system has gone before .... (thwap! quit that!).....matt sez
ENOENERGY..... but thinks it would be neat....
Oops. Sorry. I must be tired this morning- Thanks for the comments- but
I think I'll go with instant gratification....