[SLOF] [PATCH slof v3 5/5] fdt: Pass the resulting device tree to QEMU

[Alexey Kardashevskiy]

This is the mail I wanted you to comment on. Thanks!


On 05/10/17 14:26, Alexey Kardashevskiy wrote:
> On 05/10/17 03:40, Segher Boessenkool wrote:
>> On Tue, Oct 03, 2017 at 11:13:51PM +1100, Alexey Kardashevskiy wrote:
>>>> +: fdt-properties ( phandle -- )
>>>> +    dup encode-int s" phandle" fdt-prop
>>>> +    >r
>>>> +    s" "
>>>> +    BEGIN
>>>> +        r@ next-property
>>>> +    WHILE
>>>> +        2dup
>>>> +        2dup r@ get-property
>>>> +        not IF
>>>> +            2swap fdt-prop
>>>> +        THEN
>>>> +    REPEAT
>>>> +    r>
>>>> +    drop
>>>> +;
>>>
>>>
>>> Doing as below still works but brings the time for the huge guest (256
>>> CPUs, 256 E1000) down to 366ms as it does not search for properties every
>>> time but just iterates through them, I picked this from ".properties". So
>>> we are back in business :) But I'd really love someone to explain me how
>>> that works as I am unable to parse this kind of internals myself... Segher,
>>> please.
>>
>> I'll try.
>>
>> : link>name  cell+ ;
>> : name>string  char+ count ;
>>
>> A wordlist is a linked list, offset 0 of each record is a pointer to
>> the next.  At offset 1 cell is the per-name data: a flags byte, a byte
>> that is the number of chars in the name, and the actual chars.
>>
>> Well.  The wordlists are themselves a linked list; offset 0 holds the
>> address of the next wordlist, and offset 1 cell holds the address of
>> the first name record.  Like:
>>
>> STRUCT
>>   cell FIELD wid>next
>>   cell FIELD wid>names \ the head of the list of name records
>> END-STRUCT
>>
>> STRUCT
>>   cell FIELD name>next
>>   char FIELD name>flags
>>   char FIELD name>count
>>   0    FIELD name>chars
>> END-STRUCT
> 
> 
> These do not exist in the existing SLOF code, you just typed them here, right?
> 
> I want to put these into slof/fs/node.fs right after the node struct
> definition with some comments about what points to what.
> 
> 
>>
>>
>> The default (find) implementation (from engine.in):
>>
>> : ((find))  ( str len head -- 0 | link )
>>    BEGIN dup WHILE
>>       >r 2dup r@ link>name name>string string=ci IF \ if found the name:
>>          2drop r> EXIT THEN \ return a pointer to this name record
>>       r> @ \ follow the linked list
>>    REPEAT
>>    3drop false ; \ nope, not found
>>
>>
>>> : fdt-properties ( phandle -- )
>>>     dup encode-int s" phandle" fdt-prop
>>>
>>>     node>properties @ cell+ @
>>
>> "properties" in a node struct is a wordlist, which is just a pointer
>> to the first name record in that wordlist.
> 
> 			( phandle )
> node>properties @	( properties-wordlist )
> cell+ @			( properties-names-next )
> 
> And properties-names-next points to the first 'name>next' thingy. Ok.
> 
>>
>>>     BEGIN
>>>         dup
>>>     WHILE
>>>         dup
>>>
>>>         link>
>>
>> : link>  link>name name> ;
> 
> Ahhh. I was searching for 'LINK_X3E' but it is:
> col(LINK> LINK>NAME NAME>)
> 
> Ok. Another confusion was that 'NAME' here does not point to a string but
> to 'name>flags'. Ok.
> 
> btw what does 'lfa' stand for in stack comments?
> 
> 
> So, after 'link>', the stack is:
> 			( properties-names-next end-of-name )
> 
> 
> And after that end-of-name there is/are what? One 'xt' there returns
> data+len, where does that token come from? I assume next one is 'xt' which
> prints from 'ls', right? All I am getting it all wrong and there is just
> one xt?
> 
> 
>> where name> moves to after the name (cell-aligned):
>>
>> : name>  char+ dup c@ 1+ chars+ aligned ;
>> (skip the flags byte, get the char count byte, skip that many bytes
>> (and the count byte itself), align).
>>
>>>         dup >name name>string 2>r
>>>         execute
>>>         2r>
>>>         fdt-prop
>>
>>> name tries to find the name, given an xt.  You do not need it here.
> 
> 
> Well, with this new knowledge - sounds like the name is right there between
>  properties-names-next and what 'link>' returns so I do not need extra work
> to extract it.
> 
> '>name' simply goes backwards to the beginning of the name, right (if I am
> reading the beginning of slof/fs/base.fs correctly)?
> 
> btw '.property' still does search, what is that - room for a little
> improvement or I am missing something again?
> 
> 
>>
>>>
>>>         @
>>>     REPEAT
>>>
>>>     drop
>>> ;
>>
>> So maybe more like
>>
>> : fdt-property ( link -- )
>>    dup link> execute rot link>name name>string fdt-prop ;
> 
> Without stack comments, I'll forget this in 2 months maximum.
> 
>> : fdt-properties ( phandle -- )
>>    dup encode-int s" phandle" fdt-prop
>>    node>properties @ cell+ @ BEGIN dup WHILE dup fdt-property @ REPEAT drop ;
> 
> 
> With this formatting and missing stack comments I will stop understanding
> it in a week :(
> 
> 
>> (and maybe better names?  Something that makes clear it is copying
>> properties to the flat tree).
> 
> It does not work like this, if you do not like the name - do not just say
> it, suggest a better one ;)
> 
> 
> 
> and thanks for the lesson!
> 
> 


-- 
Alexey