Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>]

Hi Ian,

Given that the Debian bug is filed so either way we have a path forward,
should I get started with the discussion about shipping the hardware
(get various approvals, prepare boxes for shipping, etc.)? That's going
to take a few weeks for sure. Or would you like to wait for the Debian
bug to be resolved / alternative code to be written ?

Cheers,

Stefano


On Mon, 5 Nov 2018, Ian Jackson wrote:
> Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
> more messages] [and 2 more messages] [and 2 more messages]"):
> > AFAICT, Ian's main concern was adding yet another dependency on external 
> > entity.
> 
> We could put the .deb repository on xenbits.
> There remains the question of who will do the manual rebuilds.
> 
> Another thing that occurred to me is that not all kernel .debs are
> created equal.  Do ones that come from the kernel source tree, without
> any of the Debian packaging code, interact properly with Debian's
> initramfs and bootloader update machinery ?
> 
> > However, OSStest already provides scripts to build kernel. So why would you 
> > want 
> > to use Dockerfiles/ViryaOS?
> 
> That seems to me to be a very salient point.  Earlier I wrote:
> 
>    Ie the biggest work here of all kinds is is glue.  Adding more
>    entities to the problem will increase rather than reduce the amount of
>    glue code that needs to be written.
> 
> The amount of new glue that is needed depends also on how much of the
> existing systems can be reused.
> 
> 
> I am starting to think that it may have been a mistake of me to
> explain in clear and precise detail what would be needed, to have
> osstest directly use its own-built kernels for baremetal install.
> 
> If you look at the length of my description it looks like a lot of
> work.  But the competing proposals are being described by some
> handwaving.  Obviously they look simpler then!
> 
> No-one has written a comparabily detailed plan for exactly what work
> would need to be done, and what risks there are, for example in this
> scheme to use docker and ViryaOS and an apt repository.  It's true
> that such a plan would have fewer changes to osstest; but more of it
> would be manual steps.  In the case of manual steps IMO a comparably
> detailed plan would include a rough set of proposed command line
> runes, etc.  I'm not even sure that this scheme has been thought
> through enough for us to write such a plan with confidence that it
> will work.
> 
> Almost certainly such a detailed plan, if we can write it, would be
> considerably longer and more complex than the plan I posted earlier.
> 
> And of course it has a higher overall maintenance burden because
> updates would be manual forever more - not only manual, but also
> dependent on the dockerfile continuing to work, which means the manual
> steps depend on the availability (and integrity!) of whatever external
> entities the dockerfile uses.


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