On Mon, May 06, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
> Antonio Terceiro <[email protected]> writes:
> > *But* if the setup does not use a master image, the `master` device type
> > should be the coice, since it was entirely designed with the assumption
> > that there *is* a master image.
> 
> Yes, this assumption is a major problem for more "direct" use of LAVA
> for regular kernel development.
> 
> After a almost 2 weeks of tinkering with LAVA (including making piles of
> hacks and changes to the code), I've come to the conclusion that there
> are fundamental design decision in LAVA that make it very difficult to
> use for kernel development.  Unfortunately, I don't have any more time
> to spare to make it work.
> 
> > We should probably write a new device type for this use case.
> 
> The device type is only part of the problem.  I've written a custom
> device type for treating u-boot as a "master image" and using boot_cmds
> to directly boot the test kernel.  But there are still several other
> places that assume a master image.

I think I was not clear enough in my post.

LAVA has a set of device type implementations (i.e. Python classes) to
handle the interactions with different devices/setups:

lava_dispatcher/device/fastboot.py
lava_dispatcher/device/fastmodel.py
lava_dispatcher/device/qemu.py
lava_dispatcher/device/sdmux.py

lava_dispatcher/device/master.py
lava_dispatcher/device/uefi.py
lava_dispatcher/device/vexpress.py
lava_dispatcher/device/highbank.py

When you create a device-type configuration file, you specify which one of
those implementations you want to use, like this:

$ grep client_type 
lava_dispatcher/default-config/lava-dispatcher/device-types/nexus.conf
client_type = fastboot

The default client_type is `master`, which is the right choice for most setups
that do use a master image. Since your device-type conf file does not say
anything, it is using `master`, which is not what you want. With a proper
device type implementation, all the problems you faced will go away.

(the naming is a little confusing; when we say "device type" we might mean the
Python implementation or LAVA configuration items in device-types/foo.conf.
The fact it's called client_type in the configuration file does not help)

For example the qemu¹, fastmodel, and fastboot types, for example, do not
assume a master image, and a new implementation for this use case would look a
lot like them.

¹ 61 LOC

-- 
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org

Attachment: signature.asc
Description: Digital signature

_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation

Reply via email to