Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 1 Nov 2018, Lars Kurth wrote:
> On 01/11/2018, 11:30, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:
> 
>     On Wed, Oct 31, 2018 at 6:46 PM Stefano Stabellini
>     <sstabellini@xxxxxxxxxx> wrote:
>     > > > ---
>     > > > + Baremetal boot from Debian stable or stable-backports:
>     > > >
>     > > > In order to avoid cross-compilation, Osstest must be able to 
> install a
>     > > > bare-metal system on the host itself in order to build Linux and Xen
>     > > > test binaries for that host. At the moment osstest uses Debian for
>     > > > this, and there is no facility in osstest for building custom 
> kernels
>     > > > for this purpose.  As such, a suitable Linux kernel binary which can
>     > > > boot baremetal on the proposed hardware must be available from 
> Debian
>     > > > (at least `stable', or, if that is not possible, 
> `stable-backports').
>     > > > Osstest cannot install using a patched version of Linux, or one 
> built
>     > > > from a particular git branch, or some such.  If the required kernel 
> is
>     > > > not available in Debian, the vendor should ideally work with the
>     > > > Debian project to ensure and validate that Debian stable-backports
>     > > > kernel binaries boot on the proposed hardware.  Alternately, the
>     > > > vendor can work with the community to implement the necessary
>     > > > functionality within osstest to enable it to build custom kernels 
> for
>     > > > build installs, or use alternate distributions which have better
>     > > > baremetal support for the hardware.
>     >
>     > If we want to grow Xen on ARM testing in OSSTest for embedded boards, I
>     > think that requiring Debian kernel support is unrealistic,
>     
>     You keep using the word "requirement" as though it's an active choice
>     that is being made.  This is a checklist for what kind of hardware can
>     currently be integrated into the XenProject test lab; it is not a
>     policy document or a design document.  As such, it should reflect the
>     situation as it exists at the moment, not how we would like it to be,
>     or how we think it may be at some point in the future.  At the moment,
>     only kind of hardware which can actually be integrated is one on which
>     Debian will boot; so this is listed as a criterion.  There's no point
>     buying hardware which only boots on the XenProject Linux tree until
>     osstest can actually boot such hardware.
>     
>     It also includes pointers for how to change the situation.  If and
>     when the situation changes, we can change the document.

It looks like this thread wasn't the right one to raise my concerns
about embedded testing in OSSTests. If this doc is just describing what
the situation is today, then, of course, Ian should go ahead and commit
it as is. He knows best what the situation is like.

FYI I have been talking with Ian about sending Xilinx MPSoC boards to
the COLO for OSSTests usage for a while now. Ian wrote that he would
send "a checklist for OSSTests hardware". When I saw this email I
thought that this was it, and I interpreted it as requirements.


> I agree with George and Ian. The document describes what is possible now. 
> Part of the rationale for this document, is to enable Ian to off-load more 
> responsibility related to adding machines to OSSTEST to Credativ (from 
> procurement to putting machines into service). This will free up some of 
> Ian's time to focus on development work. The project pays for the service by 
> Credativ by the hour: to manage costs we need to ensure that we don't blow 
> the allocated hours budget (which already happened once this year). Anything 
> which does not work with OSSTEST out-of-the box or cannot work because there 
> is no OSSTEST support will very quickly burn through the project's support 
> budget. Thus, we need to define boundaries to avoid running up costs for 
> tickets in the order of several thousands of USD.
> 
> If we want to increase Arm testing, the necessary functionality has to be 
> implemented in OSSTEST. I don’t think you can expect Ian to implement such 
> functionality in OSSTEST, given all the other work which is already on his 
> plate: although I believe Ian stated several times that he would help someone 
> else to do this.
 
Unfortunately, looking at my schedule, I am unable to provide help on
this front in the foreseeable feature :-(

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel