[OpenBIOS] next-property

Olivier Danet odanet at caramail.com
Sat Jan 25 21:49:06 CET 2014


On 25/01/2014 13:58, Mark Cave-Ayland wrote:
> On 03/01/14 19:16, Olivier Danet wrote:
>
>> On 03/01/2014 17:09, Artyom Tarasenko wrote:
>>> On Thu, Jan 2, 2014 at 2:43 AM, Olivier Danet <odanet at caramail.com>
>>> wrote:
>>>> I may have found a bug in OpenBIOS.
>>>>
>>>> An OS uses the "nextprop" iterator to scan device properties, and
>>>> eventually
>>>> asks about nonexistant properties.
>>>> "const char *obp_nextprop(int node, const char *name)"
>>>> (arch/sparc32/romvec.c)
>>>> calls the "next-property" forth code, then pops the result.
>>>> According to the standard, next-property should return 0 if the 
>>>> property
>>>> selected
>>>> is the last _OR_ if the property does not exist.
>>>> The current code in forth/admin/devices.fs returns nothing when the
>>>> property
>>>> does
>>>> not exit.
>>>>
>>>> For example (SPARC 32) :
>>>>
>>>> cd screen
>>>> " name" ?active-package next-property drop cr type
>>>> --> returns "device_type"
>>>>
>>>> " interrupts" ?active-package next-property
>>>> --> returns 0, this is the last property.
>>>>
>>>> " bozo" ?active-package next-property
>>>> --> returns nothing. Which, imho, is wrong.
>>> Actually this matches pretty much with what OBP does:
>>>
>>> ok showstack
>>> ok " model" current-device next-property
>>> fffe61e8 4 ffffffffffffffff ok drop type
>>> name
>>> ok " bozo" current-device next-property
>>> ok
>>>
>>> Artyom
>>>
>>>> Here is a patch, I am not quite sure about it (debuting Forth)
>>>> but it helps the target OS :
>>>>
>>>> Index: forth/device/property.fs
>>>> ===================================================================
>>>> --- forth/device/property.fs (révision 1246)
>>>> +++ forth/device/property.fs (copie de travail)
>>>> @@ -70,7 +70,7 @@
>>>> 2drop r> >dn.properties @
>>>> else
>>>> r> find-property dup if @ then
>>>> - ?dup if >prop.next @ then
>>>> + dup if >prop.next @ then
>>>> then
>>>>
>>>> ?dup if
>>>> ===================================================================
>>>>
>>>> The standard asks for a pointer to a zero lenght string instead of 
>>>> zero,
>>>> the C code obp_nextprop() expects a zero. I don't know if it makes a
>>>> difference.
>>>>
>>>> Olivier
>>>> (Btw, the OS is NetBSD :-)
>>>>
>>>>
>>>> -- 
>>>> OpenBIOS http://openbios.org/
>>>> Mailinglist: http://lists.openbios.org/mailman/listinfo
>>>> Free your System - May the Forth be with you
>>>
>>>
>> You are right.
>> I tried on an Ultra 10 with OpenBoot 3.12.
>>
>> next-property returns nothing when the property is unknown and also when
>> the property is the last one.
>> This contradicts Sun own documentation "Writing FCode 3.x Programs".
>>
>> Puzzled, I tried then on a Apple iBook G3 :
>> dev screen
>> " <something>" active-package next-property
>>
>> This laptop returns :
>> - true and a forth string when the property is not the last one
>> - true and "0 0" when the property is the last one
>> - false when the property does not exist.
>>
>> Anyway, whatever method is chosen (return nothing, return zero...),
>> OpenBIOS forth and/or C code ("opb_nextprop()") should be modifed to
>> avoid page faults.
>
> Hi Olivier,
>
> Do you have a revised version of this patch based upon the discussion 
> in this thread?
>
> I'm wondering whether we should simply use a [IFDEF] SPARC32 ... 
> [ENDIF] block so that your change only takes effect on SPARC32?
>
>
> ATB,
>
> Mark.

When starting X under NetBSD 6.x, it enumerates devices and
eventually asks next-property of "name" and "device_type"
  to many nodes, including "/chosen", "/builtin"...

I did not look into NetBSD to determine whether this behaviour is sane.
I have found several 'almost bugs' in NetBSD. For example the TCX 
framebuffer
should not have an address property.

Sun's OpenBOOT does not define "next-property" on 32bits, any
behavior is acceptable on that platform.

Should we make Sparc64's behaviour (silence) the default one? Answering zero
seemed more polite and simpler for the C obp_ wrapper.

I have a dozen patches waiting for OpenBIOS and QEMU.
I hope I will be able to post them next week.

Regards
Olivier



More information about the OpenBIOS mailing list