Take it away. Thanks. Thanks everyone. Welcome. Let's talk about how to go through
the network attached device using Make-O-Sign InterD. The contents would be first of
very brief, mandatory interaction about what are in the interface and why we need them.
Then a very brief mandatory interaction about Make-O-Sign InterD. Then how to translate
the missing functionality in Make-O-Sign InterD using Drake with us a reference. Finally set
up the network using an Apple Manager and two proofs of concept showing how to root
from using NFS and I discuss it. So let's start by introducing myself. My name is Antonio
Albert Féjo and I work at Sousa on the system but I need them and I work mostly on maintaining
it. I re-related topics. This is the currently integrated and open Sousa and Sousa
distribution which is Drakehood and to allow us to understand helping with the system.
So now come on. Usually scenario we start power up after that the firmware does minimally
in the service station. Then it has the controller to bootloader, to bootloader, loads
into memory, a kernel and one or more in the 30 images and then involves a kernel. The kernel
mounts the unit area in the memory of the system. Then it has the controller to it. The
unit area looks for the real root file system and once found and mounted has the controller
over to the host system manor. So let's focus on the unit area part. It is a CPR type. It
can be compressed with the optional. There may be more than one unit at this which will
be concatenated by the bootloader and also, when the system is around, it can be the PID-1 in
the unit area. So the intergenerators, most use, are very good in the RAMFS tools and making
it CPR. They all have in common that pick files from the host system and also they add
custom logic to the good process. We will talk about this custom logic in more detail later.
Then for years ago, it's basically just a smag with this idea of building the interiors.
Make a sinitary, it's a wrapper on top of the make a side, make a size, an image builder. It creates
various types using this between packages, package managers and their dependency resolution
mechanism. So it does not pick files from the host system to be the interding. Well, there
are two steps, because by default it includes the load that kernel modules from the system.
And also it can include other files if the user wants, if it is configured to the so.
And it does not have custom logic to the good process. Right now, that's in a set and a
exception, we do that rules, but already a percent will be in 2 and 80 and the end.
So let's share what I think that are the most important benefits of this approach.
It will sinitary is out of distribution packages, so the source is known beforehand.
It is easy to reproduce, it can be built of host. It is less complex, because ideally,
you have to choose only packages and carry modules. And distribution can provide to the fine
configuration sets to ship specific functionality. We have a clear and a super PACs and it stands
in fails. It should be someone else's fault. For example, if LDN2 files to scan devices in the
inner terde, it should be fault of LDN2 and not because of the inner generator. And any change
from a package will automatically apply to the inner terde, because make a signitary is not adding
custom logic or picking what files from each package will be included. And also, it fits the
maintenance effort from the inner terde, and it is available to the responsible packets.
So what's not so nice, it is fragile to packaging errors. In it does this serve
using more than 100 packages, but on the hand, I will narrow the three and users. It can be
a little detected. And in it the regeneration can be as low, but in proofs, it is because it
uses package manager gases if enabled on the host. The size of the inner terde is large.
There are two approaches to work around this. One is fixing the packaging. For example,
the splitting packages which are very big into the packages like with GLC, with the locals and
us with packets. And the other approaches using the removed files configuration.
And in open system, we were shipping a file, a configuration file, which is the moving
things are needed in the inner terde, like hand pages, cell completions, etc.
And also, I would like to support all the executors in 64 and R64.
And the last thing is intended only for hostility in it. I mean, the funny thing is no hostility
is available with the inner maker side program, but there was an attempt to add hostility
switch and it was rejected. So, how to implement this in functionality in maker as an iterative
for that, I would use a drake with a reference, drake has been around the previous 15 years or so,
and it is the most widely used in the early generator and it works quite well.
So, first thing I did was create a personal fork. So, there I could remove everything I didn't
need, like, no system in the code, unnecessary messy options. And after this cleanup, I could focus
and understand more easily how the functionality is implemented in difficult modules.
So, ideally, I would like to translate every drake with functionality into maker side configuration.
So, maker side configuration can consist of any teleconfiguration files
and extra custom file system to this. And this custom file system 3 is allowed to have an
intermediate state between getting things working and send them to the right up history.
So, how to translate drake with modules into maker's configuration. First, how to identify things
that in every drake with module. Identify binaries, units, libraries and at the packages that provide
them, identify stock and modules and do the same thing at the kind of modules in configuration.
Identify hooks, we will talk about hooks later, but hooks are, as functionality that drake
provides to allow to run a custom sweep at certain point in the good process.
So, how to rework this scripts to be independent of drake with lip, other service in makers
I actually ordered like a drake with dash hook service, pointing, actually started to this script
and then after working, I'll send to the right place. And finally, identify custom system
in the units with every rules, binaries, check if they are required. First, save them in makers
I extra, then, opposite. So, we know how to solve things and what about the custom logic?
We will analyze these six points in the tail, break points, break points, start carrying
common line options to pause, to stop the good process at certain point and drop to work interactive
shell. This is basic for the paving and alternative will be implemented directly in
this is already done and will be included in the next system liberation.
And the good thing about this is now we can stop the good process at the switching route
without the dot press. Next, pass the kernel from a line for that drake provides
pass functions, but the alternative will be that the pack just can provide a binary to this one.
And for example, network manager is already doing that.
Extending a slush plot in the line with files in configuration and drake allows to
extend the kernel command line not only when it builds territory, but only when the system is
booting. And alternative, since this will not be spot by extended,
the only option that I can pick off is use the what the bootloader allowed to define is
that really. Next, hoops, hoops are points that allows to inject and run
externally sweep at certain points in the good process. Also can be injected at build or
while resisting is booting. And drake with the south source, this is creeps during the
build process using its custom drake task system researchers. So the alternative will be
instead of asking drake to run as creep. Packages can provide their own system researchers properly
over. Next, the unit queue. The unit queue allows to wait until all the necessary hardware
has been discovered because the hardware detection is asynchronous. So drake could implement
a blocking loop with several hoops. And it loops until you get a set of and all the
clips in the queue finish straight on through. The alternative is thinking about
ordaining after system users settle would be wrong. Because there is no, we don't know when
the hardware would be ready. So the better alternative would be, not services can subscribe to
you that I haven't seen react when and you hardware is discovered. Using the listening net
property and subscribing to AFK link you have some current events, system in that will be
is doing something similar. So it's a good example of that. But maybe we need to implement
something like this in the future. And the last one is unpacking a load in the
shutdown. This allows to perform plan ups using two special hoops for take with modules.
The alternative is that this is already available in system this shutdown. We can run
a scripts located in this directory. And for example, in the again, it's already 51.
Okay, let's start with the main part of this talk. To put from an appuratized device first,
we need to set up the network for that I chose the network manager because it's the network
100 I use. Although I think that the system the network is should work out at the top.
So first, identify packages, network manager at least. Identify code modules,
makers are in a terriat, currently loaded network modules. If we need more, we have to set
that in configuration. And then analyze what tray could you do in a custom logic.
It's installing a custom configuration file. Then it has two custom system services. The first
one is to set up the network. The second one is already out to the first one and checks whether
we are online. So we will keep both. And also, he installs one hook once in the live hook to
parse the coordinate command line. The good thing is that the binary that he's using is already
provided by the network manager. So we can ship a service properly over calling this binary.
Although I think that maybe a system is in a relatively better instead of regular service
to parse the kernel command line and affect the file unit, okay, depending on that. But for now,
I think this like tray could be. And also, reduce the scope. Use only the network manager
in penalty HP client. So this new services will be order the first one right up to the boot
and before you there parse the carrier command line. We set up the network between network
pre-target and network target. And we said whether we are online between network target
and network online target. So the picture will look like this. We have the configuration file
with the pack to define. If we need more kernel modules, we have to add then there.
And the custom functionality should be up streaming to network manager. I have already
opened a match request and the first feedback was very good. They know they are the best
spontaneous for this functionality. So hopefully it will match soon. And after that, even tray could
be patched to use these services instead of their own custom services. Next, NFS, the same process.
Identify packages, NFS client, live NFS ID map, RPC blind. Identify kernel modules,
the NFS NFS tree, NFS HGLKO, and net sum RPC. And then what tray could
do in a custom logic? It still sim the line hook to parse the carrier command line and also
a few depth hook to start RPC. So I will match both into a existing service order before you
have. Next, NFS root is clip, which actually is the one from Mount NFS. And I would
rate a match in service for that. And finally, a plan up hook to perform plan ups before switching
root. So these new services will be ordered right at, right at the good,
parse the kernel command line and start RPC before you there. After Nargot of Night Target and
remote FS target Mount NFS and right before switching root, profile plan ups.
So this is the whole picture, new staff in blue. We have the NFS configuration here,
are in the packages and the terminal modules. And the new functionality that should be
upesting to NFS utils. And it first to polish this and think about using a generator also to parse
the kernel command line. And finally, I will discuss. I will discuss here is more tricky than in the first,
but the first part is actually like the previous one, the first identify packages should be open.
I discuss here in I discuss here you are here with modules. It should be under drivers, I discuss
with three, but for now I will take the whole tree. And then the custom vehicle functionality,
which is very tricky, because it has a similar line to parse the kernel command line. But
you also parse the kernel command line and I discuss here with the script. And it makes us both
handling of hardware and kernel command line options on the same script. So I analyze what I have to do
and decided to split the functionality in two parts. One read, I discuss parameters for feedback,
a service specific for that. And two services to analyze, to parse the kernel command line from
the kernel command line. So for if the I discuss parameters are provided for feedback,
which does not one service, the mistake here will be that some of low cars don't even need
network to get the parameters from buyers. But for now I will leave this as a proof of concept.
And then to get a configuration from kernel command line first, a service to parse the kernel
command line before I discuss the service and after the register. And start the target after the network
is not like and before remote access feedback. So again the picture is similar to the previous one
with NFS. We have one configuration file defined in packages and kernel modules and custom functionality
that need to be upstream into work and I discuss at the policy. So the conclusion should be
not found any block has yet that can be implemented. It is a benefit for classification
it originators because they can adapt, remove their custom logic to the new upstream functionality.
Also benefit for distributions because it is at least improved packaging. And for me,
make a sign that is doing the right thing, which is being as dumb as possible. I mean not adding
custom logic but selling to the right up streams. And one to end with a question, it is a
good alternative for some use cases but could it become a food replacement for a traditional
internet reader? Let's request the question open because there is a lot of work to do here.
And rate code is very, there is a lot of dependency in rate code everywhere but you know,
let's see what happens with time. So what's next, policy and appsty in NFS and is
cassey more than it was that like NVME over TCP, multi path, there is a lot of work to do
if you want to continue this line. So reference and that should be it.
Do you want to take some questions? Do you have any questions? I would just want to go with my
microphone. Okay. Thank you for the talk. I'm Benjamin working at Knoggle and we plan to switch
to breakout. So the question is, do you have plans to switch to MKOSI? In the RD at some point,
how do you see the future? So what do you say make a sense? Does it make sense for other
distribution like a bunch of web in the search and record before saying, okay, let's move to the next
big thing? We don't have plans to switch to make OSI in it at the, but we are analyzing
the good things it brings. I mean, which is, it allows to claim rate code for example. Yeah, definitely.
And that's great. And it has limitations. I mean, I don't know if it's suitable for all these cases.
For, I mean, it's not a replacement, but maybe for some use cases is good, but for everything,
it lasts a lot of things. Let's see, I mean, there is not anything blocking the technology here.
So it is, if the planning, if people want to continue investing, working on it.
So it's, can you list what's lacking? Sorry? Can you list which features are missing from MKOSI?
Features? A lot of them. I mean, I mean, I'm only implemented NFS and an ISK asset proof of concept,
but Drake with us, like MBD, multi-path, MBME over TCP, MBME over five other channels, and to have everything
to take with you one. And also architecture support, like S390, I would like to see, we don't have anything like that,
and I request that. That's doing it with. I mean, there is a lot of misinformation on it.
Thank you. And thank you for your talk. In line with the question of the previous person,
and do you maybe have things like Seth or maybe GlusterFS on your roadmap?
In a roadmap. Oh, he's not a roadmap.
No, but I'm a proud Debian and Seth user, and yeah, I would be lovely if it would support Seth, I guess.
But just to note it, and maybe you've got time, maybe you don't, but that is mentioned, didn't I?
Okay. Thank you. There was another one there. Hello, it's interesting. I like it. I have a question,
which is not relevant in 95% of cases, but I wonder, how does it compare to Dracula in terms of
how quickly it generates the image? Is this lower, right? I mean, the packages are gas,
the speeding uses, but it is as lower than the echo. I mean, the echo is not installing like
because this uses a make-or-side, which is behind using Super BNF, Pac-Man, whatever,
which is installing the packages, then removes what you don't need. So this is lower. I don't have
specific numbers, but. Okay, and thank you very much, Anthony. I haven't got time for any more questions.