Antonio Terceiro antonio.terceiro@linaro.org writes:
On Thu, May 02, 2013 at 03:54:25PM -0700, Tyler Baker wrote:
+1 on Michael's suggestion to use dummy_deploy
I've had some conversions with Kevin about his use requirements for LAVA, and here is a summary:
- For kernel testing, the kernel binary + ramdisk is provided over tftp. I
think he has figured out how to override the boot_cmds so this is not an issue.
- Would like to utilize lava-test-shell however lava-test-shell makes
assumptions about the rootfs. His idea is provide all the lava-test-shell support scripts in the ramdisk. All his existing tests are already included on this ramdisk.
Perhaps we can create another "type" for deployment data called "vanilla"
"actions": [ { "command": "dummy_deploy", "parameters": { "type": "vanilla" } }, { "command": "boot_linaro_image" } ]
Target.vanilla_deployment_data['distro'] = 'vanilla' Target.vanilla_deployment_data['lava_test_sh_cmd'] = '/bin/bash' Target.vanilla_deployment_data['lava_test_dir'] = '???' Target.vanilla_deployment_data['lava_test_results_part_attr'] = '???'
This "vanilla" target could carry the assumption that the lava-test-shell support scripts are already on the target...somewhere.
If the ramdisk is passed explicitly to LAVA,
It's not.
It might be an initramfs (built into the kernel), or it might be a rootfs on MMC that already contains a bunch of tests.
Here, we should have the option of avoiding the whole tar-it-up, download, reboot cycle that lava-test-shell currently does.
then we could make a copy of it, them let lava-test-shell add its stuff inside the copy, and use that instead of the original ramdisk to boot the kernel.
I'd rather see a skeleton package for the lava-test-shell stuff needed on the target so it can be pre-installed.
Kevin