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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

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.

Thanks,
Ian.

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