[U-Boot] Command unit test failure?

[Simon Glass]

Hi Stephen,

On 30 May 2014 13:18, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 05/30/2014 12:07 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> I am seeing the failure below when I run the unit tests. I noticed it
>> a while ago but thought I might be doing something wrong. Any ideas?
>
> git bisect says:
>
>> git bisect bad
>> 95fac6ab4589ec0767b1eac662577866e2b2f423 is the first bad commit
>> commit 95fac6ab4589ec0767b1eac662577866e2b2f423
>> Author: Simon Glass <sjg at chromium.org>
>> Date:   Thu Feb 27 13:25:58 2014 -0700
>>
>>     sandbox: Use os functions to read host device tree
>>
>>     At present we use U-Boot's filesystem layer to read the sandbox device tree,
>>     but this is problematic since it relies on a temporary feauture added
>>     there. Since we plan to implement proper block layer support for sandbox,
>>     change this code to use the os layer functions instead. Also use the new
>>     fdt_create_empty_tree() instead of our own code.
>>
>>     Signed-off-by: Simon Glass <sjg at chromium.org>
>>
>> :040000 040000 02b649e6f0c3f84f8aff31938ec869ec6ccd964c 1d48977cfbcbb855b2ee2de2bd20b43a39db7837 M    common
>> :040000 040000 7982835c46f491ed54f289b79f2ad1567e8f135b a543335107459fb1a759b262573904fd18b8c683 M    disk
>
> No doubt the change to disk/part.c in that commit broke the syntax "host
> - $filename" for the "sb save" and "test -e" commands. Is there some
> alternate syntax that sandbox should use to access the filesystem, and
> hence the unit test commands should be using?

OK thanks for digging. The alternative feature is the block device
framework, which sandbox now supports - see f4d8de48. This allows us
to see host files as block devices, potentially containing filesystems
that U-Boot supports. It enables sandbox to use filesystems,  One day
we might have a filesystem test that uses this.

Having said that it seems clear that host file access is a useful
feature for testing in sandbox (at least!), and we really need it
independently of the block device interface. The implementation that
was dropped was just a work-around and we don't have a full
replacement yet.

But we really shouldn't use the same name 'host' for the host device.
I'm not actually sure if that would work.

If you have time to take a look please do (I have a bit of a queue),
otherwise I'll see if I can come up with something that keeps both
features enabled.

Regards,
Simon