Re: [PATCH v9 0/5] Introduce Python bindings for libfdt

[Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]

Hi David,

On 16 March 2017 at 22:07, David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> On Tue, Mar 14, 2017 at 08:20:53AM -0600, Simon Glass wrote:
>> Hi David,
>>
>> On 4 March 2017 at 16:52, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> >
>> > At present libfdt consists of only a C implementation. Many scripts are
>> > written using Python so it useful to have Python bindings for libfdt.
>> > Apparently this has never been attempted before, or if so I cannot find a
>> > reference.
>> >
>> > This series starts the process of adding this support, with just a
>> > bare-bones set of methods.
>> >
>> > The v8 series provides binding that can be used like this:
>> >
>> >     fdt = libfdt.Fdt(open(fname).read())
>> >     node = fdt.path_offset('/subnode@1')
>> >     print fdt.get_prop(node, 'compatible')
>> >     subnode = fdt.first_subnode(node, quiet=[libfdt.NOTFOUND])
>> >     while subnode > 0:
>> >         print fdt.get_name(subnode)
>> >         subnode = fdt.next_subnode(subnode, quiet=[libfdt.NOTFOUND])
>>
>> Just checking in to see how this looks now? I sent one v10 patch but
>> the rest is as is. Let me know if you'd like me to send the whole
>> thing again.
>
> Sorry, my day job has been kind of hectic lately.
>
> So, for one thing, yes, I'd like a repost of the whole set - I didn't
> keep the last spin ready to hand.
>
> But I'm also still not thrilled with the behaviour in the v10 patch
> you posted. It prints information _only_ if there are failures, which
> makes it a drag to check, and confusing since the tests show up in the
> final numbers but have no other visibility.
>
> I think this can go one of two ways:
>    - Give the Python tests close to the existing testcases.  I realize
>      that's awkward since they use python unittest not the existing
>      home-rolled framework, but do what you can.
>
> or
>    - Don't integrate the python tests at all.  Have make check run the
>      existing testsuite, then the python test suite (if python is
>      available).  This should produce *some* output for both parts in
>      all cases (so you know it has run), even if it's just a minimal
>      summary for the unittest part.  Don't include the python tests in
>      the totals for the other part.

It's pretty easy to just always print the output. I'll send that as
v11 and see what you think.

Regards.
Simon