So, everyone, my name is Mark Bikua, I'm from Samsung R&D City of Poland, and today I'm
going to present a project I've been working on for throughout the last year, which is
CI Multiplotform.
So first, if you words about myself, I have background in FPGA engineering, and that Samsung
I'm working mostly on platform software.
The main goal for me was recently porting Tizen OS to respite, and then supporting some
system libraries, and porting them to respite, and because of that, I also got involved
with CI and the enablement of CI for respite.
So jumping straight into the problem, I'm trying to solve with a multiplotform, so if you
have a library or an application that has some platform specific code, because some specific
optimizations or some specific behavior, which is very much platform oriented or architecture
oriented, then you need to either cross compile it, or try to do some weird stuff, and
you quickly run into an issue that if you have some dependencies, you need to somehow include
them in the build, then you need to somehow run the test, and it can get really tricky
fast.
And second point is that when you're trying to push your code upstream, maintainers need
confidence in your code.
So in our case, we are trying to upstream our respite vector extension support for a
pixel library, and well, there was no support for respite in CI pipeline at 3dc.org
at this time, and so the maintainers simply didn't know the specifics of respite vector,
so we couldn't really prove that we are able to do the stuff that libraries needs.
And third point is hardware scarcity, so in case of respite, there are no respite CI runners
available pretty much, and also the boards that supported respite vectors at the time were
pretty scar, so the maintainers couldn't really just go by a board and test our patches.
So let's try to make a multi-architecture CI as boring as possible, I want to base it
on reusable GitLab CI templates, it's GitLab because we target the 3dc.org at first.
We want to use layer to CI or Docker images to have flexibility for the projects.
We want to use user mode emulation because we don't have a harder support for everything,
and we also want to include coverage and coverage summary across all the targets that we have.
So what are the building blocks?
First we have the OCI images, which are a layer, so you can have depending on your project
you could have a base GNU layer, then add LLVM as well, if you want to test both compilers,
then you can add your build tool, in our case we support for now, we have plans to extend
it to see make-and-autotals, and then you can add another layer with your project dependencies,
then we have reusable templates, in our case as I said it's only for resin, but if you have
your own scripts that you want to run on those different targets you can use it, and we
extensively use a QME user mode, which pretty seamless integrates with the OCI images.
A few words about targets naming, so we have currently Linux 90 targets and Windows
cross compilation targets using wine, then we have native and cross targets, because for
some targets, for example, 32 bits, big end-ion maps, there is no DBN image, so unfortunately
we need to cross compile for those targets, and then the final part is the architecture,
so how to use the project, here's a little bit kind of call for action, if you have some
platform specific code in your project and you use GitLab CI, then you can try to use this,
so first you need to check which targets have native runners on your GitLab instance,
currently we support natively, GitLab.com and free desktop.org runners, which is X86 and
ARM, second, do I need custom dependencies or build system, if yes, then you need to define
those layers on by yourself, if not then you can straight-up use pre-built images, and then
either if you use Amazon then it's great because you can use the templates which we provide,
or if not you can just run your specific build and test by yourself, on the left you can
see basically example using parallel matrix for three different architectures, running some
basic script, so if you hope takes that's what we came here for, so how to make it
all possible, we have DBN based images, we chose DBN because it has the widest support
for different architectures, first there are multiple natively supported, official architectures
and also there is extensive library of ports for DBN, so for the upstream pre-built images
we can just pull them from upstream and use them, but for the ports we need kind of elaborate
setup, in this case I tried to do this on a little privilege, the possible runners, so first
we have build main builder image, this is our first layer of abstraction, then we have the
build-strap builder base image, it's standard DBN tool for building base images, and then
we have the DBN base image builder layer which internally uses prudes, which adds another
layer of abstraction, and it was pretty fun debugging, it all in CI, and yeah it's I was
really skeptical at first if it will work, but magically it works in one very specific version
of a Dora base image, but it works, and that allows us to utilize OCI caching, so that we
don't need to rebuild the DBN images every time we run the CI, and that allows us to have
the very similar base line, because the bird type and the bootstrap are the tools that
are used for the official upstream images, so we have very similar base images for all the
architectures that we support, and then on top of that as I said we build additional layers
so GNU tool chain, OVM, Amazon, and whatever you have in your project, yeah second nice
nice thing about utilizing QMU for running the test is, well first you can of course have
your native runners, if you have risk five boards and you can add them to your CI, then that's
great, but on the other hand utilizing QMU allows you to have some very specific virtual target
configuration, so in case of risk five vectors, you could configure the vector length vector
register length in QMU, which allows you to easily change the virtual hardware configuration,
and that's actually allowed us to cache some early bugs in our RVV implementation, and yeah
it extends platform coverage beyond what is already available, so at this time that we're developing
the patches we had only board with VLAN of 256, but in future there will be boards with bigger
VLANs, and right now we can test those scenarios and be ready for future hardware, so what's
next for the project, first it's a call for action to all of you, if you have a project that
has some platform specific code, then I'm really happy and it runs on GitLab, and I will
really happy if you came and tested it, I would really appreciate any kind of feedback and
the back reports, you could push them to the official GitLab repo, and if you have any suggestions
what could be done to improve this, of course besides adding more features, but what are the
specific scenarios that you see useful for you, there's also this nice batch that you can stamp
on your project if you're using CI multi platform, and in the pipeline there are more
build tools, so we plan to support also CI make and auto tools with extensive templates and
coverage summarization, yeah I think it's really nice to have this aggregate coverage summary
because if you have multiple targets then well you have multiple summary ports for different
targets, but then you're able to compress all this into one single result and present it nicely
in GitLab for example for pull request, yeah so that's about it, here's the QR code for the project,
and yeah please contact me, please use the project and I would very much appreciate the feedback
and if you have any questions, I'll be there around or I'll answer questions online.
That's five minutes that you can take questions now, yeah that would be great actually.
So do we have questions for one question?
Can I say something about performance and entity when you're running about difficulties
on our electrical knowledge?
Yeah so the question is about the question is about performance penalty when you're running
QMU, so well first of all sometimes running in QMU is the only way because you don't have the native runners
and in case of risk five actually because there are starting to appear some options to include native runners for risk five
and we tested them with the cloud V cloud five runners and curiously the current hardware is slower than QMU running on
QMU like big runners available at pre-dustable torque, so that's interesting thing.
On the other hand when you have some similar extensions in case of risk five it runs much slower than on real hardware
so it's kind of trade-off, so for building images I would say running with QMU is the fastest
if you have some very specific performance oriented code then using the native runners is always the best idea
and this project allows you to interchange those, so you could build your images on the native runner
and then use the QMU runner and then use the native runner to run your actual tests.
Any more questions?
Yes, the question is about integrated integration with QMU basically, so honestly I'm not really familiar with how QMU
does CI, so I'm not sure but what you could do for sure is to just mirror your repo on some GitLab instance
be it's the official GitLab.com or pre-dustable.org or wherever and you could just grab those templates
but yeah I'm not 100% certain how it works on code work, so any other questions?
Are you having one more question maybe?
You have three minutes, I need one more.
Yeah, so the question is about why not cross compiling, so it's an option for sure for some projects
but once you get to more and more complex projects which like multiple dependencies and maybe some
target specific dependencies then you quickly run into a lot of maintenance overheads when trying to do it properly
and yeah in case of CI multi platform it's much easier because you have basically native
the DB images in your dependency layer you could just upgats whatever dependency you need
and you don't need to worry about cross compiling those dependencies and so on so
and because we use OCI multiple targets for the OCI images you could have very specific dependencies
for each platform that you support so you don't need to have like one set of dependencies you could
have multiple variants of dependencies based on the platform.
Thank you very much.