On Tue, Jul 31, 2012 at 3:33 PM, Paul Larson paul.larson@linaro.org wrote:
On Tue, Jul 31, 2012 at 8:40 AM, Marcin Juszkiewicz marcin.juszkiewicz@linaro.org wrote:
W dniu 30.07.2012 16:10, Alexander Sack pisze:
Hi,
big items we need to sort out:
- linaro-media-create install support
- lava-test support
- lava support
I had some thought on it (OpenEmbedded builds and LAVA) and due to that here are some questions.
I haven't heard much about our OE plans, but would like to... are there further details of what we're looking to do here somewhere? Is this just for v8, or for other things too?
Currently it's mainly for ARMv8, but who knows what might be coming later on :-) If it's successful, we'll probably have more requests to develop projects with it.
Also, the ARMv8 work should really be starting in the following weeks.
- Do tested image needs to have LAVA client code installed?
If it does then I would have to add LAVA client components into OpenEmbedded because I can not use Ubuntu packages as they are not compatible with each other.
Not really, lava-test can be installed easily on the target once it's deployed, but to the best of my knowledge, I don't think anyone's really tried running lava-test under OE. We would need pip to install it, and possibly a few other python dependencies. The bigger problem here is that lava-test was always fairly dependent on apt for a number of things. This can be worked around telling it not to gather a list of packages installed when it runs, but many of the tests rely on dependency installation via packages.
The first idea I had was to basically have a way at lava-tests to skip the step which it installs the test dependencies. At least with that approach, we could already have the dependencies in place for the test cases we care about.
Otherwise, we'd need a way to dynamically install the dependencies, which can be quite complicated with OE as we'd need to create and export a repository.
One of the things I've raised in the past that we should look at is consolidation of lava-test and lava-android-test by means of a host driven test framework, and this is one reason why.
Can you explain more about how this host driven test framework would work?
Looking to the future, I think we want to support more than ubuntu and android, and maybe even more than OE. Adding a lava-something-test every time is not going to be the best way to go about it.
I agree, and this is something that most test suites have to deal as well. The only easy way to be generic enough, is to build the test cases and the dependencies natively at the image (or at least make sure the image already delivers a basic set of dependencies by default).
- Does lava build require rootfs + hwpack or can boot with just rootfs?
Rootfs will contain kernel in /boot/uImage and u-boot configuration in /boot/boot.scr (or other defined location). If hwpack is required then I will have to create one with OE and add support for them in l-m-c (as we can not use Ubuntu packages for things other than kernel/bootloader cause there is no warranty about binary compatibility).
Certainly the dispatcher will have to support another means of installation, just like we have to for Android images. If linaro-media-create is used, then this makes things slightly better, but I'm sure it'll need at least a bit of special handling in the dispatcher, though probably not as bad as android was. I don't foresee a big problem here.
I believe we could even use the hwpacks we produce for Ubuntu here, but only dealing with the kernel and bootloader (skipping all other packages). As we don't care much about upgradability, we could have a logic at linaro-media-create to just extract the debian packages related with the kernel and bootloader (something that happens in some way anyway).
With that logic in place, we could support any rootfs, even Android (and share the same basic set of hwpacks we also use at Ubuntu).
Cheers,