Okay, just test. Yeah, that seems to be working. So, hello, welcome everyone. So, today we're
doing a small presentation about a tool that we came up at work with that's called
Film Reaction. It's as the title says, helps building you all kinds of filmwares and we
don't go into more detail here yet because filmreaction can be used for a multitude of things.
So first of all, who are we? I'm Marvin, a filmre developer working at nine elements
as my shirt says here and this is my lovely co-worker. Hello, I'm Woike, can I do DevOps
mostly? I did, so it's good. So, what we want to go over today is building filmre is usually
hard to do. For some reason, there are so many build systems and it's always difficult to get
a hold of all of them, understand all of them especially if you're working in more than one project.
Then we go over what is actually filmreaction and how does it help us? So, short introduction
to Jocker and a helper tool called Dagger and then we do an example and maybe if the
demo gods are on our side also working demonstration. So, first of all, building filmwares.
If you come across building host filmwares, BMC filmwares embedded filmre not so creative
name, it's an action, it's an action that builds filmre. So, what is it? It's kind of
similar to what you know from make file or task file. It just calls into different things
and abstract things the way you even further and yet now you might be saying oh yeah,
yet another build system. How does that improve the whole situation? Did you want to get
rid of some build systems? And it's not really a build system per say. It's simply just
a executor of commands under known circumstances and doesn't really build stuff itself.
So, it gives us a unified environment using container technology. It doesn't need to be
darker just anything that speaks OCI images and builds in CI and builds locally are always
the same given that we now have containers on our side and it doesn't matter if you're building
on windows, if you're building on Mac, if you're building on Linux, you get the same results
throughout anyone using the system. It's written and goes so it can cross compile to almost any
architecture that goes supports. We still have some minor issues with paths but that's up to
be fixed. It has get up action integration already but it is very low effort to integrate into
other CI-CD systems that are not GitHub. It just started out there and we also packaged version
for the AUR. So, what you usually see when you split some CI systems and your local development,
you have some build Yamels or other scripts, whatever GitHub uses right now and locally you might
have some additional shell script to just call into all your tools so that you don't need to type
all of the Mac commands or whatever tool is being used in that and this all together then fetches
obviously you code that you have locally or in your remote repository and builds the thing.
And now with our unification we have the same results in CI and local by just using the tool
plus its configuration which is written in JSON and obviously the code and configurations of
your tool that you previously had. So with that I'll switch over to Voytech to I'll
explain a bit more about Docker and how Dagger fits into the builds. Hello, hello.
So, does any of you actually know Docker have you heard about that?
Oh, nice. So, essentially Docker is a somewhat a virtualization environment for
often used for development. It allows you to package together all kinds of dependencies
for all kinds of systems, doesn't matter if you are running or a Fedora, you can still
Dockerize debion packages for example. It's very convenient, you can use different versions,
you can use all the versions. So, it is super great thing for development and hence we wanted to
use it for this but we couldn't use it standalone that's where the Dagger comes in.
Dagger is a Docker orchestrator. It sits on top of it and essentially it allows you to take a
Docker container and execute commands inside it. Define environment variables also things like that.
So, it's programmable CI-CD engine essentially. The idea is that you could create your CI-CD
once in Dagger and then run it everywhere. In GitHub, locally, GitLab, source hard, whatever comes to your
mind. So, we decided to use this to basically leverage what we wanted to do. And that's the
core technology. So, the example that we have made, this is from the example repository,
this is the JSON configuration. So, for example, over there the fourth line you have SDK URL
that's the URL to the container you want to use to build in this case, core boot.
We pre-build all of the containers so you don't have to build them yourself. We have multiple
versions, dating back, I think the oldest is for 19 something like that. We also have
EDK2, Linux, whatever you name it. So, you define your container there and then you define
additional paths like where is the core boot repository that you're trying to build.
There is the configuration file for your core boot and so on. Where do you want to output the result
of this endeavor? You can also define blobs like Intel FSB, management engine, things like that.
It will automatically figure out what to do with them and put them in. So, that's a very nice thing
if I do say so myself. Also, at the bottom you can define inputs. So, the whole idea behind this
is that you can define a core boot module. You can also define EDK2 module, U-Root module, Linux
module and then you can pipe output of one into the next one. So, you can build the whole stack in
one single loop for which we have a recursive build. In GitHub, this is the Yamalo that you could use.
You have some kind of checkout of your repository where you might have the core boot or other
projects as a GitHub modules or whatever you fancy as alternative. Then you just call
the interaction with the configuration file which module you want to build and if you want to build
it recursively means it will build all of the dependencies like Linux, U-Root, whatever you might
define there. In the end, you just upload the artifacts to the GitHub. It's as easy as that.
If you want to run the same thing locally, you just install the interaction or compile it from
the sources called build and again config target and if you want to do recursive build or not.
If you want to abstract this way a little bit more and make it a little bit more convenient,
you could also use something like task file where you define that you want standalone
core boot or you want core boot with Linux, big thing. You can define some variables and so on.
So, essentially that's the whole premise. Then we have a demo if that will work. So, let's try that.
Okay. So, while you're preparing the demo, another good thing is about that all of these containers
one thing about dagger is it will use API calls into any container engine. So, the default is to
use Docker but if you have popmen or just raw container D or whatever, what it will do is whatever
it finds on your system. It will run API calls. Those are defined directly in the go code and
based on what you've written in your in an outputs will turn this into a familiarly created containers,
mutate them on the fly and outputs whatever you define there. So, essentially you tell it what
goes in what goes out and how to operate with that and then it will just in those containers which
have a specifically known good environment for each of these firmware stacks that we already
predefined call their build systems. It will not touch any of their build systems. So, it will
operate as if you're just doing that locally except now much more conveniently and with much more
confidence that your environment does not affect the build if it's running on your machine or if
it's running on a co-work machine. Yes, so here's the example of the JSON configuration file
right now we support only JSON but we might extend it to more system slater. So, in this example
we have a co-boot which is supposed to have a Linux kernel baked in. So, here you define that it
depends on the Linux kernel. Here you define the Linux kernel. You also define that Linux will use
its own container made for that and you can also say this Linux container will use a
urode inside and here below you define your urode and with these dependencies then you can
have the whole tree defined like so. All right, so I already tried to execute this because
it's a demo but yeah demos are always very funky so let me clear this.
Perfect. So, I have defined the task file which does only finger action dash build dash dash
config dash dash target. In this case it's built the co-boot with Linux and because I already
built it before it has already everything cached it detects there are no changes in the sources
so it will not try to rebuild them. It just shows you everything is up to date. So, the urode is up to
that's the one module that has no dependency at all Linux which depends on the urode. It's also
up to date and then the core boot which depends on the Linux also up to date. So, basically you're done.
I could try to maybe how much time we have?
Oh, nice. So, if we, how many seconds?
The core idea which is part of the project? So, the core idea which is part of the project is that
oftentimes these build systems especially if they consist of multiple parts take away from
developers' time you need to fill around with them too much and especially if you're changing
something in Linux when you have a core boot Linux boot urode stack and then you need to figure
out which you need to rebuild now. Do I need to rebuild only the kernel or do I need to change
something here now as well? Now, you can focus solely on just coding and rerun the build system
and it will figure out for you where things changed where it knows how to rerun some stuff.
Plum things together and you can just focus on coding, run building and you get a binary out of it.
Just so that more time can be spent doing things that are actually
I'd say important to do and not to care about because building something should be easy and it
should always be the same so this is how we created it. I think it's where mostly at a point where
we can already move into a round of questions. Okay, so this is an example where he removed some of the
caches. I didn't really remove the caches. I just touched the read me in Linux kernel so
now it will not rebuild your root because that's already up to date but it will try to rebuild
the Linux kernel because I just changed one file so it is rebuilding that and then it will also
rebuild the core boot because that depends on this Linux kernel so that's the whole idea of this
dependency tree. So I guess now questions. Yes.
So it does require some Windows 2 links and it actually just expects the Windows user space
for the FSP. We did some hex there to pull in some of the Microsoft 2 links into Linux
environment and make them work and it really makes it environment. It works. It's still kind of
Linux container but the setup is so finicky that abstracting it away in a simple container just
tells us to make this work more properly. It's basically requires what EDK2 requires with some
extra sprinkled on top. Yes, we lose the changes to the vendors or customers directly so
I think as a hobbyist there is no legal way to obtain them but otherwise you can obtain them from
Intel with set vendor license. Yes. Sure, we could do that. It's basically a matter of
figuring out the licensing because there are so many projects involved that we need to make sure
that whatever we distribute is actually redistributable especially if blocks are involved
because firmware action does allow to supply you a arbitrary amount of blocks and those are often
tricky when it comes to licensing but other than that I see no issue in doing that. For now we just
cared about the tool itself and not what it actually outputs itself. That's mostly for internal use
right now but for all the public stuff I see no problem doing that. What you think in the
way, firmware files that aren't really going to be used to provide damages without them and then
how to script things like that. Yeah, sure. There's also a way that's just called a stitching stage
where you could do exactly that already in firmware action. Just provide like everything as a
block and then tell it where everything goes in the binary and then it will do just that. But you
can also use any other tool. It's just convenient for us to just have one tool that does it all.
Any more questions? I think that's not the case and with that we can end few seconds early.