Subject: Confusing return values for OF_* functions.
To: None <port-sparc@netbsd.org>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: port-sparc64
Date: 06/07/2001 04:14:45
OpenFirmare functions that return handles has irregular return values
that signal error conditions.

As an example: OF_peer returns 0 if there are no more siblings, but
OF_instance_to_handle returns -1.  While this is what 1275 specifies,
this is highly confusing, as both methods return phandle but use
different values to signal "ENOENT", so to say.

OF_open is even more confusing, as 1275 specifies that the returned
ihandle is zero if open fails, but OF_open returns -1 if a call to
openfirmare failed.  While we *might* care to distinguish a failed
open (zero) from failed call to client interface (-1), in practice we
don't.

In sparc64 there are actually few places in dev/consinit.c that do

    if ((node = OF_instance_to_package(stdout)) == 0)

though, instance-to-package uses -1 as error indicator!

For sparc using -1 probably doesn't match the OBP2 convention (though
I don't have FCode v2 manual handy right now), so code that calls
prom_* ops will be confused by -1 when it tests for zero as the error
value (that's how I discovered this, I booted JS10 to see if it can
make it as far as panic in bootstrap() when it can't find
/obio/interrupt - to my surprise it crashed in getprop(-1, ...)!).

Another example: on sparc prom_findnode returns 0, but
obp_v2_finddevice (effectively, just a recursive prom_findnode)
returns -1 on error.


I think we should standardize on zero as "ENOENT" handle value.  My
understanding is that for sparc we just have to do it to match OBP2
(so that promlib layer is consistent across OBP2 and OF).  Dunno about
sparc64, but at least I hope that the report of the wrong test of
OF_instance_to_package return value was useful for you guys ;-).


Comments?

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen