John Plocher writes:
> James Carlson wrote:
> > That's exactly the point.  Nobody has promised to provide anything
> > other than human (English only!) readable messages here.  The contents
> > of the messages are no kind of programming interface.  They're not
> > documented anywhere.  
> 
> A quick search of docs.sun.com found several places where we
> document these kinds of messages.  I'm sure that there are others
> on bigadmin as well...

I was somehow led to believe that man pages define the stable
interfaces on Solaris -- not admin guides, not bigadmin entries, and
not blogs.

> > If the Ethernet cable is plugged in, find out whether or not 
> > the Ethernet hub does a link integrity test. Then become 
> > superuser to check and possibly set the machine's NVRAM. If 
> > the hub's link integrity test is disabled, set this variable 

TPE?  Is that the Solaris name for SQE?  What a blast from the past.

In any event, this part:

> > # eeprom | grep tpe
> > tpe-link-test?=true

... is wholly irrelevant.  Doesn't exist on modern platforms.  The
newest one I can find that has this is an old Ultra 2.  Good luck to
anyone trying to rely on that.

> > Programs that depend on them are engaging in hackery.  
> 
> I am not talking about programs that depend on these interfaces,
> but humans who need this information themselves.  We have trained
> them over the years to look in syslog for this type of debugging
> information.

That part I agree with.  But you were bringing up log-grovelling
applications as a reason for keeping this data intact and for
asserting that it's some sort of stable interface.

> > That's exactly what this case is attempting to accomplish.  The first
> > step is getting those logging messages into the framework where (if
> > they exist at all) they belong.
> 
> I'd agree with all you have said, with the addition of
>      ... without losing the useful information already provided by
>      some of the drivers.

Garrett's latest offer appears to do that.  I'm not at all comfortable
with it (I'd rather see the messages just plain torched), but it seems
like a decent compromise.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to