Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages]"):
> This is fine by me
Thanks, pushed now.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
On 15/02/2019, 15:40, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages]"):
> as mentioned earlier, I think we need a legal/admin item for hardware and
donations. See proposed addition below.
...
> LEGAL
> =
I would prefer not to bake the Linux Foundation address into this
document, nor to have it be the primary repository for legal details,
if that's OK.
How about this:
LEGAL - XEN PROJECT
===
The Xen Project Test Lab runs public tests, and provides access to its
hardware to Xen community members so that they can debug the code.
Accordingly there must not be any restrictions on publication of
information such as test results, nor any restrictions on access to
the hardware. Ie, the Xen Project is not able to agree to any
nondisclosure agreement (NDA).
The Xen Project Test Lab does not accept hardware on loan. We
purchase it, or, following prior consultation and approval, can accept
donations. For donations, the Linux Foundation requires a letter
confirming some legal details. The Community Manager will provide
a list of specific requirements for that `donation form' letter.
This is fine by me
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages]"):
> as mentioned earlier, I think we need a legal/admin item for hardware and
> donations. See proposed addition below.
...
> LEGAL
> =
I would prefer not to bake the Linux Foundation address into this
document, nor to have it be the primary repository for legal details,
if that's OK.
How about this:
LEGAL - XEN PROJECT
===
The Xen Project Test Lab runs public tests, and provides access to its
hardware to Xen community members so that they can debug the code.
Accordingly there must not be any restrictions on publication of
information such as test results, nor any restrictions on access to
the hardware. Ie, the Xen Project is not able to agree to any
nondisclosure agreement (NDA).
The Xen Project Test Lab does not accept hardware on loan. We
purchase it, or, following prior consultation and approval, can accept
donations. For donations, the Linux Foundation requires a letter
confirming some legal details. The Community Manager will provide
a list of specific requirements for that `donation form' letter.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
Ian,
as mentioned earlier, I think we need a legal/admin item for hardware and
donations. See proposed addition below.
On 15/02/2019, 11:57, "Ian Jackson" wrote:
Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages]"):
> So overall, for the reasons I explain, I'm going to commit this
> document (subject to the other comments etc.) *with* the requirement
> that hardware must be supported by Debian (at least, in -backports).
This didn't happen. THere was considerable further discussion. The
fact that various kinds of uncertainty meant this document didn't get
committed is now blocking us giving the go-ahead for some new hardware
acquisition:
...
From fae48bd584a0b58934a2df97b6db1d06eacf1724 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Tue, 30 Oct 2018 16:12:27 +
Subject: [OSSTEST PATCH] README.hardware-acquisition
New document-cum-checklist, for helping with hardware procurement.
Signed-off-by: Ian Jackson
CC: in...@xenproject.org
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
On 15/02/2019 12:56, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
> more messages]"):
>> So overall, for the reasons I explain, I'm going to commit this
>> document (subject to the other comments etc.) *with* the requirement
>> that hardware must be supported by Debian (at least, in -backports).
>
> This didn't happen. THere was considerable further discussion. The
> fact that various kinds of uncertainty meant this document didn't get
> committed is now blocking us giving the go-ahead for some new hardware
> acquisition:
>
> Ie, I can't answer the question "should we accept hardware XYZ"
> without reference to at least an implied a checklist like this.
> Having written it down I ought to use the one I've written down,
> because to do otherwise is simply to pointlessly invite mistakes. And
> if I'm to use a written-down checklist it should be one which is
> actually official.
>
> Accordingly, I intend to commit this to osstest now. Juergen, this is
> just a document: can I have your release ack for it ?
Yes, sure:
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages]"):
> So overall, for the reasons I explain, I'm going to commit this
> document (subject to the other comments etc.) *with* the requirement
> that hardware must be supported by Debian (at least, in -backports).
This didn't happen. THere was considerable further discussion. The
fact that various kinds of uncertainty meant this document didn't get
committed is now blocking us giving the go-ahead for some new hardware
acquisition:
Ie, I can't answer the question "should we accept hardware XYZ"
without reference to at least an implied a checklist like this.
Having written it down I ought to use the one I've written down,
because to do otherwise is simply to pointlessly invite mistakes. And
if I'm to use a written-down checklist it should be one which is
actually official.
Accordingly, I intend to commit this to osstest now. Juergen, this is
just a document: can I have your release ack for it ?
I will then reply separately about the specific new hardware, using
the checklist as a guide. Obviously a checklist is always a
guidelines document: if we find that a point is best answered a
different way than the checklist expects, or that the checklist ought
to be changed, then changes to the checklist are a reasonable part of
the outcome of such a process; that would be in the form of further
patches to this document in osstest.
Ian.
From fae48bd584a0b58934a2df97b6db1d06eacf1724 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Tue, 30 Oct 2018 16:12:27 +
Subject: [OSSTEST PATCH] README.hardware-acquisition
New document-cum-checklist, for helping with hardware procurement.
Signed-off-by: Ian Jackson
CC: in...@xenproject.org
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Hi Stefano, On 02/11/2018 23:44, Stefano Stabellini wrote: On Fri, 2 Nov 2018, Julien Grall wrote: On 02/11/2018 17:56, Stefano Stabellini wrote: On Fri, 2 Nov 2018, Ian Jackson 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. Basically, you are saying that even if had a well maintained deb repository of kernel packages for OSSTest to use, doesn't matter how we achieve this goal, it would still require a non trivial amount of work to do the integration with OSSTest. This is not how I understood the thread. I believe this was related to use an external CI loop. In our case, once we have a deb package. Then this is not much different than using a backport kernel. We already have such support in Osstest, so it should not be too difficult to adapt it for a different repo. OK, I misunderstood Ian, thanks for stepping in. If that is the case, then: 1) We already have a Xen ARM Linux tree which we have to maintain for Dom0 The maintenance model and testing of this tree doesn't change regardless. 2) We already have Dockerfiles and scripts by Doug and ViryaOS to build kernels on gitlab We could improve them to build a full deb repository. Which does not work on Arm today... (see the previous discussions). Lars and Wei are working towards addressing this. What's stopping us from using (2) to setup up a Xen Project deb repo? Does it really matter who executes scripts (2) and whether they are run on your laptop or in the cloud as long as the build is fully reproducible? We are not talking about hacking config files around and using who knows what compiler to build something. docker build will give you the same output no matter the host. AFAICT, Ian's main concern was adding yet another dependency on external entity. However, OSStest already provides scripts to build kernel. So why would you want to use Dockerfiles/ViryaOS? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition
[and 1 more messages] [and 2 more messages] [and 2 more messages]"):
> Basically, you are saying that even if had a well maintained deb
> repository of kernel packages for OSSTest to use, doesn't matter how we
> achieve this goal, it would still require a non trivial amount of work
> to do the integration with OSSTest.
No, sorry. The one thing that osstest can easily consume is a
well-maintained deb repository.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
On Fri, 2 Nov 2018, Julien Grall wrote: > On 02/11/2018 17:56, Stefano Stabellini wrote: > > On Fri, 2 Nov 2018, Ian Jackson 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. > > > > Basically, you are saying that even if had a well maintained deb > > repository of kernel packages for OSSTest to use, doesn't matter how we > > achieve this goal, it would still require a non trivial amount of work > > to do the integration with OSSTest. > > This is not how I understood the thread. I believe this was related to use an > external CI loop. > > In our case, once we have a deb package. Then this is not much different than > using a backport kernel. We already have such support in Osstest, so it should > not be too difficult to adapt it for a different repo. OK, I misunderstood Ian, thanks for stepping in. If that is the case, then: 1) We already have a Xen ARM Linux tree which we have to maintain for Dom0 The maintenance model and testing of this tree doesn't change regardless. 2) We already have Dockerfiles and scripts by Doug and ViryaOS to build kernels on gitlab We could improve them to build a full deb repository. What's stopping us from using (2) to setup up a Xen Project deb repo? Does it really matter who executes scripts (2) and whether they are run on your laptop or in the cloud as long as the build is fully reproducible? We are not talking about hacking config files around and using who knows what compiler to build something. docker build will give you the same output no matter the host. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
On 02/11/2018 17:56, Stefano Stabellini wrote: On Fri, 2 Nov 2018, Ian Jackson 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. Basically, you are saying that even if had a well maintained deb repository of kernel packages for OSSTest to use, doesn't matter how we achieve this goal, it would still require a non trivial amount of work to do the integration with OSSTest. This is not how I understood the thread. I believe this was related to use an external CI loop. In our case, once we have a deb package. Then this is not much different than using a backport kernel. We already have such support in Osstest, so it should not be too difficult to adapt it for a different repo. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages] [and 2 more messages]"):
> On 02/11/2018 15:44, Ian Jackson wrote:
> > We have more x86 capacity and are deploying some dedicated build
> > hosts. But cross-compilation is more complex (particularly the
> > compiler conflict...)
>
> Do you mean the multilib problem? This issue is only when cross-compiling
> tools
> (which I would not recommend anyway...). For things like kernel and
> hypervisor,
> you don't need multilib.
Yes, that problem.
I think by `cross-compiling' here you mean to include running gcc -m32
on an amd64 host or vice versa, which is not quite real
cross-compiling in my view. But it does require gcc-multilib.
But, as it turns out, you are right that this is not a problem for
osstest. When osstest does builds for an i386 dom0, it does the
hypervisor build on an amd64 host and the tools build separately on an
i386 host.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
On Fri, 2 Nov 2018, Lars Kurth wrote: > I thought that we could have provided a deb repository with alternative > kernels for OSSTests to use. We would have scripts to generate those deb > packages from the Xen ARM Linux tree in a repository on xenbits, but we > wouldn't necessarily have OSSTest run the script. Initially, we could > run the scripts by hand, then, we could run them automatically in > OSSTest or elsewhere. Is that a possibility? I already have Dockerfiles > (AKA bash scripts) to build an ARM kernel on a few distros, that's > something I could make available. > > This morning Julien had one more different suggestion: building the > kernel with OSSTest on SoftIron, that we know it works, it would be a > native compilation. Then we could use the built kernel together with the > Debian installer on the other boards (Xilinx, Renesas, etc.) > > Either way, the kernel to be used with the embedded boards doesn't need > to be rebuilt often, only once a month or so. > > That would fit with the https://gitlab.com/xen-project/xen/container_registry > model > where we store Dom0 baselines as containers for builds via the Gitlab CI > > This may be a stupid idea, but I wanted to make sure that we consider all > options This is not a stupid idea -- it is exactly the kind of thing I had in mind too ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Hi,
On 02/11/2018 15:44, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages] [and 2 more messages]"):
On 02/11/2018 15:05, Ian Jackson wrote:
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
Linaro hosting is pretty reliable. But AFAIK, they don't have an apt repo for
the toolchains. We would need to download a tarball and unpack it.
That would be doable. If the tarballs have versions we could put the
version number in the osstest config and then it would be push gated.
Perhaps Julien has time to do that.
Arm64 cross-compiler in Debian should be suitable enough for building the
kernel. If there are any issue with them, then a bug report should be filled.
OK, that's definitely going to be easier then.
My preference is to avoid cross-compiling if we can. This would avoid to use x86
resource for building kernel that could be re-used for testing Xen itself.
We have more x86 capacity and are deploying some dedicated build
hosts. But cross-compilation is more complex (particularly the
compiler conflict...)
Do you mean the multilib problem? This issue is only when cross-compiling tools
(which I would not recommend anyway...). For things like kernel and hypervisor,
you don't need multilib.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages] [and 2 more messages]"):
> On 02/11/2018 15:05, Ian Jackson wrote:
> > I guess that's probably tolerable. We'd have to think about whether
> > we should snapshot them, or install them directly from upstream. The
> > latter is less coding effort in osstest (just add an apt source and
> > run the install rune I guess) but it would imply tracking these in an
> > uncontrolled way, so we would want to be confident that they are
> > maintained to a high standard, since problems with the compiler would
> > break everything for us. Also I would ask: how reliable is their apt
> > repository hosting ? If it goes down, likewise, everything would
> > break for us.
>
> Linaro hosting is pretty reliable. But AFAIK, they don't have an apt repo for
> the toolchains. We would need to download a tarball and unpack it.
That would be doable. If the tarballs have versions we could put the
version number in the osstest config and then it would be push gated.
> > Perhaps Julien has time to do that.
>
> Arm64 cross-compiler in Debian should be suitable enough for building the
> kernel. If there are any issue with them, then a bug report should be filled.
OK, that's definitely going to be easier then.
> My preference is to avoid cross-compiling if we can. This would avoid to use
> x86
> resource for building kernel that could be re-used for testing Xen itself.
We have more x86 capacity and are deploying some dedicated build
hosts. But cross-compilation is more complex (particularly the
compiler conflict...)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Hi,
On 02/11/2018 15:05, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages]"):
Thank you for the detailed answer and the willingness to see osstest
changed in this respect.
Sure. It's not fixed in stone, and a variety of approachs will fit
into it I think.
Let me premise that as much as I would like this to be done, I had a
look at my schedule, and, realistically, I can only volunteer very
little time on this. In regards to the two Xilinx boards, it looks like
we'll just have to wait for Debian.
OK. That's perhaps less work overall at our end anyway. Let me know
if you think any aspect of this is getting stuck somehow; I have
contacts in Debian which I could use to enquire or whatever.
On Thu, 1 Nov 2018, Ian Jackson wrote:
The prerequisite is obviously an appropriate cross-compiler. Will the
Debian cross-compilers do ?
Probably it would work, but I don't know for sure. Most people use the
Linaro compiler and toolchain:
https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
Linaro hosting is pretty reliable. But AFAIK, they don't have an apt repo for
the toolchains. We would need to download a tarball and unpack it.
Testing the Debian cross-compiler would be very easy.
Perhaps Julien has time to do that.
Arm64 cross-compiler in Debian should be suitable enough for building the
kernel. If there are any issue with them, then a bug report should be filled.
[...]
Wei Liu writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages]"):
Debian's cross-compiler package conflicts with its native compiler,
Specifically it conflicts with the multilib style native compiler used
for Xen. This is a bug in Debian but it is intractable because of the
approach of the Debiabn GCC maintainer, so we will have to live with
it.
However, this is not a blocker because osstest could use a dedicated
x86 setup for the ARM cross builds. That's not ideal because it
shares resources less well, but it's certainly workable.
But maybe we just want to build on ThunderX. That leaves steps 4-6 of
my plan, which almost any approach (other than fixing the kernels in
Debian) require.
My preference is to avoid cross-compiling if we can. This would avoid to use x86
resource for building kernel that could be re-used for testing Xen itself.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition
[and 1 more messages] [and 2 more messages]"):
> Thank you for the detailed answer and the willingness to see osstest
> changed in this respect.
Sure. It's not fixed in stone, and a variety of approachs will fit
into it I think.
> Let me premise that as much as I would like this to be done, I had a
> look at my schedule, and, realistically, I can only volunteer very
> little time on this. In regards to the two Xilinx boards, it looks like
> we'll just have to wait for Debian.
OK. That's perhaps less work overall at our end anyway. Let me know
if you think any aspect of this is getting stuck somehow; I have
contacts in Debian which I could use to enquire or whatever.
> On Thu, 1 Nov 2018, Ian Jackson wrote:
> > The prerequisite is obviously an appropriate cross-compiler. Will the
> > Debian cross-compilers do ?
>
> Probably it would work, but I don't know for sure. Most people use the
> Linaro compiler and toolchain:
>
> https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
> https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
> Testing the Debian cross-compiler would be very easy.
Perhaps Julien has time to do that.
> > If the Debian cross compilers are OK, then I think the necessary
> > changes to osstest are:
...
> I thought that we could have provided a deb repository with alternative
> kernels for OSSTests to use. We would have scripts to generate those deb
> packages from the Xen ARM Linux tree in a repository on xenbits, but we
> wouldn't necessarily have OSSTest run the script. Initially, we could
> run the scripts by hand, then, we could run them automatically in
> OSSTest or elsewhere. Is that a possibility? I already have Dockerfiles
> (AKA bash scripts) to build an ARM kernel on a few distros, that's
> something I could make available.
Everything that osstest consumes should either be either:
(i) snapshotted and push gated, so that osstest always uses a version
that it itself has previously tested
(ii) maintained to a very high standard of quality and availability.
For things for which we take approach (ii), regressions of any kind,
or unavailability of the download server, cause what is effectively a
whole-system outage for osstest: every test run ends up plagued by
whatever lossage is going on. Implying no disrespect, but doing (ii)
for a kernel apt repository is very hard.
So I think (i) would be more appropriate. That would mean generating,
periodically, a whole new apt repository, alongside the old one.
Presumably they would have the generation date in the filename, like
our Debian installer images do. Updating would involve a commit to
the osstest config file, which is push-gate-controlled.
Overall I think, though, that this is probably not the best approach.
What you are saying is that you do not have the effort to automate the
building of kernel binaries, and instead you propose to do it
manually. That seems like a false economy.
The task of automating the building of kernel binaries is points 1-3
of my plan to cross build the kernels and use the result for baremetal
builds; that's not the hardest part.
> This morning Julien had one more different suggestion: building the
> kernel with OSSTest on SoftIron, that we know it works, it would be a
> native compilation. Then we could use the built kernel together with the
> Debian installer on the other boards (Xilinx, Renesas, etc.)
Yes, that is also a possibility. But it still involves steps 4-6 from
my plan.
> Either way, the kernel to be used with the embedded boards doesn't need
> to be rebuilt often, only once a month or so.
Of course we shouldn't waste it, but computer time is much cheaper
than human time. osstest already has mechanisms to optimise by
reusing builds where appropriate. The easiest thing is to tell
osstest `we want a kernel built like this' and it will DTRT.
Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages]"):
> Either way, the kernel to be used with the embedded boards doesn't need
> to be rebuilt often, only once a month or so.
>
> That would fit with the https://gitlab.com/xen-project/xen/container_registry
> model
> where we store Dom0 baselines as containers for builds via the Gitlab CI
>
> This may be a stupid idea, but I
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
On Fri, Nov 02, 2018 at 10:16:48AM +, Lars Kurth wrote: > Hi all, > > adding Wei because of ... > > User facing part: https://gitlab.com/xen-project/xen/pipelines > Back-end: https://gitlab.com/xen-project/xen-gitlab-ci > There are also some scripts in > http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=automation;hb=HEAD related > to this > > On 01/11/2018, 18:12, "Stefano Stabellini" wrote: > > Hi Ian, > > Thank you for the detailed answer and the willingness to see OSSTest > changed in this respect. > > Let me premise that as much as I would like this to be done, I had a > look at my schedule, and, realistically, I can only volunteer very > little time on this. In regards to the two Xilinx boards, it looks like > we'll just have to wait for Debian. > > For the sake of this discussion and brainstorming solutions, I have a > couple of questions and answers on how to support different kernels with > Debian below. > > > On Thu, 1 Nov 2018, Ian Jackson wrote: > > > Yes, we should discuss the technical details on how to use our own > > > quasi-vanilla Linux branch together with the Debian installer. That's > > > all we need AFAICT. > > > > OK. So: > > > > > > I see two possible approaches: > > > > Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to > > chain one Xen ARM kernel build from the next. (The anointed job > > feature in osstest allows a certain build to be declared generally > > good for use by other jobs. The anointment typically takes place at > > the end of a push gate flight, when the build job that is being > > anointed has been shown to work properly.) > > > > Secondly, cross-compilation on x86. > > > > I think cross-compilation on x86 is probably going to be easier > > because it is conceptually simpler. It also avoids difficulties if > > the anointed build should turn out to be broken on some hosts (this > > ought to be detected by the push gate system, but...). And, frankly, > > our x86 hardware is a lot faster. > > > > So, assuming the plan is to do cross-compilation on x86. > > > > The prerequisite is obviously an appropriate cross-compiler. Will the > > Debian cross-compilers do ? > > Probably it would work, but I don't know for sure. Most people use the > Linaro compiler and toolchain: > > > https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/ > https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/ > > Testing the Debian cross-compiler would be very easy. > > I was wondering whether we could use images in > https://gitlab.com/xen-project/xen/container_registry as baseline for > OSSTESTIN in these instances > We may be close to solving the build issues (via a WorksOnArm) via the GitLab > CI I would be wary to depend on WorksOnArm at this stage because there isn't enough information to make an informed decision. > And it should be possible to create some infrastructure to build some custom > images and put them into > https://gitlab.com/xen-project/xen/container_registry and pull them from > there. > > I don’t know whether that solves the full problem and how easy it would be: > e.g. would we still need the cross-compiler for Xen > But we could separate the Dom0 kernel / distro build from OSSTEST Debian's cross-compiler package conflicts with its native compiler, that's why Doug and I couldn't get Arm build in Gitlab CI. > > > If not then maybe this is not the best > > approach because otherwise it's not clear where we'll get a suitable > > compiler. > > > > If the Debian cross compilers are OK, then I think the necessary > > changes to osstest are: > > > > 1. Introduce a distinction between the host (GCC terminology: build) > >and target (GCC terminology: host) architectures, in ts-xen-build. > >This includes adding a call to target_install_packages to install > >the cross compiler, and appropriately amending the configure and > >make runes. Perhaps some of this will want to be in > >Osstest/BuildSupport.pm. The runvars for build jobs will need to > >be reviewed to decide whether a new runvar is needed or whether > >cross-compilation can be inferred from a currently-unsupported > >combination of runvars (particularly, arch vs., hostflags). > > > > 2. Maybe change ts-kernel-build to be able to additionally produce a > >.deb, or cpio full of modules, for use by step 5. (This should be > >optional, controlled by a runvar, since it probably doubles the > >size of the build output...) > > > > 3. Change make*flight and mfi-* to, on ARM, run the existing kernel > >build job on x86 by setting the job runvars
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
Hi all, adding Wei because of ... User facing part: https://gitlab.com/xen-project/xen/pipelines Back-end: https://gitlab.com/xen-project/xen-gitlab-ci There are also some scripts in http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=automation;hb=HEAD related to this On 01/11/2018, 18:12, "Stefano Stabellini" wrote: Hi Ian, Thank you for the detailed answer and the willingness to see OSSTest changed in this respect. Let me premise that as much as I would like this to be done, I had a look at my schedule, and, realistically, I can only volunteer very little time on this. In regards to the two Xilinx boards, it looks like we'll just have to wait for Debian. For the sake of this discussion and brainstorming solutions, I have a couple of questions and answers on how to support different kernels with Debian below. On Thu, 1 Nov 2018, Ian Jackson wrote: > > Yes, we should discuss the technical details on how to use our own > > quasi-vanilla Linux branch together with the Debian installer. That's > > all we need AFAICT. > > OK. So: > > > I see two possible approaches: > > Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to > chain one Xen ARM kernel build from the next. (The anointed job > feature in osstest allows a certain build to be declared generally > good for use by other jobs. The anointment typically takes place at > the end of a push gate flight, when the build job that is being > anointed has been shown to work properly.) > > Secondly, cross-compilation on x86. > > I think cross-compilation on x86 is probably going to be easier > because it is conceptually simpler. It also avoids difficulties if > the anointed build should turn out to be broken on some hosts (this > ought to be detected by the push gate system, but...). And, frankly, > our x86 hardware is a lot faster. > > So, assuming the plan is to do cross-compilation on x86. > > The prerequisite is obviously an appropriate cross-compiler. Will the > Debian cross-compilers do ? Probably it would work, but I don't know for sure. Most people use the Linaro compiler and toolchain: https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/ https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/ Testing the Debian cross-compiler would be very easy. I was wondering whether we could use images in https://gitlab.com/xen-project/xen/container_registry as baseline for OSSTESTIN in these instances We may be close to solving the build issues (via a WorksOnArm) via the GitLab CI And it should be possible to create some infrastructure to build some custom images and put them into https://gitlab.com/xen-project/xen/container_registry and pull them from there. I don’t know whether that solves the full problem and how easy it would be: e.g. would we still need the cross-compiler for Xen But we could separate the Dom0 kernel / distro build from OSSTEST > If not then maybe this is not the best > approach because otherwise it's not clear where we'll get a suitable > compiler. > > If the Debian cross compilers are OK, then I think the necessary > changes to osstest are: > > 1. Introduce a distinction between the host (GCC terminology: build) >and target (GCC terminology: host) architectures, in ts-xen-build. >This includes adding a call to target_install_packages to install >the cross compiler, and appropriately amending the configure and >make runes. Perhaps some of this will want to be in >Osstest/BuildSupport.pm. The runvars for build jobs will need to >be reviewed to decide whether a new runvar is needed or whether >cross-compilation can be inferred from a currently-unsupported >combination of runvars (particularly, arch vs., hostflags). > > 2. Maybe change ts-kernel-build to be able to additionally produce a >.deb, or cpio full of modules, for use by step 5. (This should be >optional, controlled by a runvar, since it probably doubles the >size of the build output...) > > 3. Change make*flight and mfi-* to, on ARM, run the existing kernel >build job on x86 by setting the job runvars appropriately. > > 4a. Teach the debian-installer driver in Debian.pm how to pick up a >kernel image from another job. It would look at a runvar >dikernelbuildjob or something I guess. > > 4b. Teach it to pick up a kernel modules from another job and stuff >them into its installer cpio before use. > > 4c. Teach it to put the kernel and modules onto the being-installed >system. > >This would be a variant of, or amendment to, or alternative to, >
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
Hi Ian, Thank you for the detailed answer and the willingness to see OSSTest changed in this respect. Let me premise that as much as I would like this to be done, I had a look at my schedule, and, realistically, I can only volunteer very little time on this. In regards to the two Xilinx boards, it looks like we'll just have to wait for Debian. For the sake of this discussion and brainstorming solutions, I have a couple of questions and answers on how to support different kernels with Debian below. On Thu, 1 Nov 2018, Ian Jackson wrote: > > Yes, we should discuss the technical details on how to use our own > > quasi-vanilla Linux branch together with the Debian installer. That's > > all we need AFAICT. > > OK. So: > > > I see two possible approaches: > > Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to > chain one Xen ARM kernel build from the next. (The anointed job > feature in osstest allows a certain build to be declared generally > good for use by other jobs. The anointment typically takes place at > the end of a push gate flight, when the build job that is being > anointed has been shown to work properly.) > > Secondly, cross-compilation on x86. > > I think cross-compilation on x86 is probably going to be easier > because it is conceptually simpler. It also avoids difficulties if > the anointed build should turn out to be broken on some hosts (this > ought to be detected by the push gate system, but...). And, frankly, > our x86 hardware is a lot faster. > > So, assuming the plan is to do cross-compilation on x86. > > The prerequisite is obviously an appropriate cross-compiler. Will the > Debian cross-compilers do ? Probably it would work, but I don't know for sure. Most people use the Linaro compiler and toolchain: https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/ https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/ Testing the Debian cross-compiler would be very easy. > If not then maybe this is not the best > approach because otherwise it's not clear where we'll get a suitable > compiler. > > If the Debian cross compilers are OK, then I think the necessary > changes to osstest are: > > 1. Introduce a distinction between the host (GCC terminology: build) >and target (GCC terminology: host) architectures, in ts-xen-build. >This includes adding a call to target_install_packages to install >the cross compiler, and appropriately amending the configure and >make runes. Perhaps some of this will want to be in >Osstest/BuildSupport.pm. The runvars for build jobs will need to >be reviewed to decide whether a new runvar is needed or whether >cross-compilation can be inferred from a currently-unsupported >combination of runvars (particularly, arch vs., hostflags). > > 2. Maybe change ts-kernel-build to be able to additionally produce a >.deb, or cpio full of modules, for use by step 5. (This should be >optional, controlled by a runvar, since it probably doubles the >size of the build output...) > > 3. Change make*flight and mfi-* to, on ARM, run the existing kernel >build job on x86 by setting the job runvars appropriately. > > 4a. Teach the debian-installer driver in Debian.pm how to pick up a >kernel image from another job. It would look at a runvar >dikernelbuildjob or something I guess. > > 4b. Teach it to pick up a kernel modules from another job and stuff >them into its installer cpio before use. > > 4c. Teach it to put the kernel and modules onto the being-installed >system. > >This would be a variant of, or amendment to, or alternative to, >Osstest/Debian.pm:di_special_kernel or its call site. The kernel's >ability to handle concatenated cpio images may be useful. > >We will want to refactor into a utility library (probably a file >of shell functions) at least some of the code in >mg-debian-installer-update for unpicking a kernel .deb (usually >from -backports) and fishing out the kernel image and the modules, >and stuffing the modules into an existing installer cpio archive. > >Whatever approach is taking, the modules in the installer must be a >subset because the whole set of modules is very large and may make >the initramfs too big to be booted. See the list of module paths >in mg-debian-installer-update. > >NB overall there are four aspects to (4): (i) arranging to boot the >right kernel; (ii) getting the modules into the installer >environment; and getting both (iii) kernel and (iv) modules into >the being-installed system. > > 5. Change make*flight and mfi-* on ARM to add the new runvar so that >ARM flights use our own kernels rather than Debian's. > > 6. Review the arrangements for reuse of existing build jobs, to maybe >reuse ARM kernel builds more often. Search cr-daily-branch for >mg-adjust-flight-makexrefs. Probably, an additional call
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition
[and 1 more messages]"):
> I am suggesting to use Debian for the installer and rootfs, but to use a
> different kernel for it.
osstest already knows how to do that in principle, because it knows
how to insert a Debian backports kernel into the Debian d-i image.
> Actually, I think it would be great to have Yocto support in OSSTest, it
> would work well on ARM and x86 but, also because it is a source
> distribution, I am not suggesting it at the moment.
`Source distribution' means that they don't distribute binaries, so
the thing would have to be built from source. On an x86 host I
guess. I see no fundamental difficulties with osstest supporting
that, but it would be some work to implement.
> It would be possible to only use the kernel from Yocto, and that would
> solve our problem, but at that point it is easier to just use our own
> Linux branch. It is more productive to discuss that option.
Right.
> Yes, we should discuss the technical details on how to use our own
> quasi-vanilla Linux branch together with the Debian installer. That's
> all we need AFAICT.
OK. So:
I see two possible approaches:
Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to
chain one Xen ARM kernel build from the next. (The anointed job
feature in osstest allows a certain build to be declared generally
good for use by other jobs. The anointment typically takes place at
the end of a push gate flight, when the build job that is being
anointed has been shown to work properly.)
Secondly, cross-compilation on x86.
I think cross-compilation on x86 is probably going to be easier
because it is conceptually simpler. It also avoids difficulties if
the anointed build should turn out to be broken on some hosts (this
ought to be detected by the push gate system, but...). And, frankly,
our x86 hardware is a lot faster.
So, assuming the plan is to do cross-compilation on x86.
The prerequisite is obviously an appropriate cross-compiler. Will the
Debian cross-compilers do ? If not then maybe this is not the best
approach because otherwise it's not clear where we'll get a suitable
compiler.
If the Debian cross compilers are OK, then I think the necessary
changes to osstest are:
1. Introduce a distinction between the host (GCC terminology: build)
and target (GCC terminology: host) architectures, in ts-xen-build.
This includes adding a call to target_install_packages to install
the cross compiler, and appropriately amending the configure and
make runes. Perhaps some of this will want to be in
Osstest/BuildSupport.pm. The runvars for build jobs will need to
be reviewed to decide whether a new runvar is needed or whether
cross-compilation can be inferred from a currently-unsupported
combination of runvars (particularly, arch vs., hostflags).
2. Maybe change ts-kernel-build to be able to additionally produce a
.deb, or cpio full of modules, for use by step 5. (This should be
optional, controlled by a runvar, since it probably doubles the
size of the build output...)
3. Change make*flight and mfi-* to, on ARM, run the existing kernel
build job on x86 by setting the job runvars appropriately.
4a. Teach the debian-installer driver in Debian.pm how to pick up a
kernel image from another job. It would look at a runvar
dikernelbuildjob or something I guess.
4b. Teach it to pick up a kernel modules from another job and stuff
them into its installer cpio before use.
4c. Teach it to put the kernel and modules onto the being-installed
system.
This would be a variant of, or amendment to, or alternative to,
Osstest/Debian.pm:di_special_kernel or its call site. The kernel's
ability to handle concatenated cpio images may be useful.
We will want to refactor into a utility library (probably a file
of shell functions) at least some of the code in
mg-debian-installer-update for unpicking a kernel .deb (usually
from -backports) and fishing out the kernel image and the modules,
and stuffing the modules into an existing installer cpio archive.
Whatever approach is taking, the modules in the installer must be a
subset because the whole set of modules is very large and may make
the initramfs too big to be booted. See the list of module paths
in mg-debian-installer-update.
NB overall there are four aspects to (4): (i) arranging to boot the
right kernel; (ii) getting the modules into the installer
environment; and getting both (iii) kernel and (iv) modules into
the being-installed system.
5. Change make*flight and mfi-* on ARM to add the new runvar so that
ARM flights use our own kernels rather than Debian's.
6. Review the arrangements for reuse of existing build jobs, to maybe
reuse ARM kernel builds more often. Search cr-daily-branch for
mg-adjust-flight-makexrefs. Probably, an additional call should be
added with some appropriate
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
> Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
> > Most of the time, the issue to boot Debian is related to the kernel.
> > Yet, the price might be too high for some of the vendors to donate the
> > hardware. [...]
> >
> > I still want to encourage vendor to work upstream but I would relax the
> > requirements here to "Xen Arm kernel branch".
>
> When you say `I would relax the requirements' you seem to be under the
> impression that this requirement is here for some kind of
> sociopolitical reason. It is not, or at least, not only.
>
> It is an actual requirement stemming from the way that osstest does
> its host installs (for both builds and tests).
>
> To build a kernel from source code involves an OS install that can be
> used for the kernel build, since otherwise there is nowhere to do the
> build.
>
> Clearly we do not want to manually create master build environment
> images, or have some kind of manually-updated build host. I certainly
> don't have time to maintain such a thing. Everything must be
> automated.
>
> Nor should the approach to setting up a build environment involve
> uncontrolled downloading of a pile of varying binaries from various
> bits of the internet (eg, a dockerfile). We need a single reliable
> and reputable place where we get the binaries for the base image, so
> that we have some idea what is going on and to eliminate or at least
> minimise uncontrolled and untracked changes to the test environment.
>
> Currently that one place we get those binaries is a Debian release
> (possibly a -backports kernel) and the files are the Debian installer,
> Debian kernel, and the Debian binary packages from the Debian archive.
> So the builds are done on a Debian host.
>
> This doesn't, in principle, have to be Debian.
>
> Take FreeBSD. It can only be built on FreeBSD and for complicated
> reasons a suitable precooked binary installer is not available. So
> for FreeBSD we make our own image using the previous FreeBSD image, in
> a kind of chicken-and-egg setup. This is quite complicated, and still
> does not work entirely right because all the inter-repo dependencies
> are apparently not captured properly yet in osstest's automation.
>
> I would be open to doing something similar for ARM but someone would
> have to write the code.
I am suggesting to use Debian for the installer and rootfs, but to use a
different kernel for it. The kernel could come from the same Xen ARM
kernel branch that we'll use later for dom0 (Julien's suggestion).
Building the kernel could be done in a number of ways we can discuss,
including cross-compiling it on x86 hosts. It is simple to cross-compile
kernels.
The ARM kernel branch won't change very often, we could start by
building Debian packages by hand for it and pushing them to a known
location. OSSTest could fetch the Debian installer kernel from there. I
am sure we could find other, better, ways to do this.
> > While I understand this point, I think this is going to limit us a lot
> > on the choice of hardware for Arm. While Debian is quite famous on the
> > Server world, this is less the case on the automotive/embedded world
> > where they tend to have there custom distribution.
>
> Obviously I'll take your word for that, although Debian (and its
> ecosystem) is also widely used in embedded contexts.
>
> In any case using the hardware vendor's "custom distribution" is
> unmanageable for a CI system, even if we were willing to go that far
> in the direction of testing using un-upstreamed (and perhaps
> un-upstreamable) code. We can't cope with one OS per kind of board.
>
> I am open to supporting other operating systems as the baseline for
> builds and tests. FreeBSD contributors are already working on support
> for that in osstest, on x86 at least.
>
> (I didn't just use Debian because I'm familiar with it. Debian is
> simply much more mature and tractable than most of the alternatives.
> It has excellent autoinstallation support, a very high level of
> organisation including corresponding source code availability and
> excellent release management. It has wide architecture support and
> generally wide support for a large variety of use cases. From a
> community point of view it is welcoming and helpful. And over the
> years it has been a good partner for the Xen Project. For all I know
> many of these things are true of Yocto.)
Neither Julien nor me are suggesting to use a Vendor's distro, not even
a Vendor's kernel. We are suggesting to use our own kernel branch
together with Debian.
> Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
> > That's right, it's a Yocto world around here. That's also what EPAM
> > uses.
>
> I am not against using Yocto but I know nothing about it.
>
> Is Yocto a binary distribution, or is it source code ? Does it do
> releases ?
>
> Is the plan then to write code to make osstest install its build hosts
> using Yocto ? Or
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]
I'm going to reply to this email twice. This email is about the
requirement in my document that the board is supported by Debian
-backports kernels, at least.
I'm replying to two mail@: first Julien's; then Stefano's.
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
> Most of the time, the issue to boot Debian is related to the kernel.
> Yet, the price might be too high for some of the vendors to donate the
> hardware. [...]
>
> I still want to encourage vendor to work upstream but I would relax the
> requirements here to "Xen Arm kernel branch".
When you say `I would relax the requirements' you seem to be under the
impression that this requirement is here for some kind of
sociopolitical reason. It is not, or at least, not only.
It is an actual requirement stemming from the way that osstest does
its host installs (for both builds and tests).
To build a kernel from source code involves an OS install that can be
used for the kernel build, since otherwise there is nowhere to do the
build.
Clearly we do not want to manually create master build environment
images, or have some kind of manually-updated build host. I certainly
don't have time to maintain such a thing. Everything must be
automated.
Nor should the approach to setting up a build environment involve
uncontrolled downloading of a pile of varying binaries from various
bits of the internet (eg, a dockerfile). We need a single reliable
and reputable place where we get the binaries for the base image, so
that we have some idea what is going on and to eliminate or at least
minimise uncontrolled and untracked changes to the test environment.
Currently that one place we get those binaries is a Debian release
(possibly a -backports kernel) and the files are the Debian installer,
Debian kernel, and the Debian binary packages from the Debian archive.
So the builds are done on a Debian host.
This doesn't, in principle, have to be Debian.
Take FreeBSD. It can only be built on FreeBSD and for complicated
reasons a suitable precooked binary installer is not available. So
for FreeBSD we make our own image using the previous FreeBSD image, in
a kind of chicken-and-egg setup. This is quite complicated, and still
does not work entirely right because all the inter-repo dependencies
are apparently not captured properly yet in osstest's automation.
I would be open to doing something similar for ARM but someone would
have to write the code.
> While I understand this point, I think this is going to limit us a lot
> on the choice of hardware for Arm. While Debian is quite famous on the
> Server world, this is less the case on the automotive/embedded world
> where they tend to have there custom distribution.
Obviously I'll take your word for that, although Debian (and its
ecosystem) is also widely used in embedded contexts.
In any case using the hardware vendor's "custom distribution" is
unmanageable for a CI system, even if we were willing to go that far
in the direction of testing using un-upstreamed (and perhaps
un-upstreamable) code. We can't cope with one OS per kind of board.
I am open to supporting other operating systems as the baseline for
builds and tests. FreeBSD contributors are already working on support
for that in osstest, on x86 at least.
(I didn't just use Debian because I'm familiar with it. Debian is
simply much more mature and tractable than most of the alternatives.
It has excellent autoinstallation support, a very high level of
organisation including corresponding source code availability and
excellent release management. It has wide architecture support and
generally wide support for a large variety of use cases. From a
community point of view it is welcoming and helpful. And over the
years it has been a good partner for the Xen Project. For all I know
many of these things are true of Yocto.)
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition"):
> That's right, it's a Yocto world around here. That's also what EPAM
> uses.
I am not against using Yocto but I know nothing about it.
Is Yocto a binary distribution, or is it source code ? Does it do
releases ?
Is the plan then to write code to make osstest install its build hosts
using Yocto ? Or is the proposal just to use a kernel from Yocto ?
Would we want to do that for all ARM hosts ?
Who will write this code and who will fix it when it goes wrong ?
> > I still want to encourage vendor to work upstream but I would relax the
> > requirements here to "Xen Arm kernel branch".
>
> +1
I am very open to this.
It does need a solution to the chicken-and-egg problem. As I say, the
required underlying concepts (for using an existing properly anointed
egg to raise a new chicken so as to generate the next egg) are in
osstest already.
Ie perhaps we could install our build hosts with a Linux image we
prepared earlier. We would pick up our own-built Linux images, and
when they pass the tests, anoint them for use in
