WEBVTT

00:00.000 --> 00:22.800
Hello, my name is John Luca Guida and there's a reason that's also a backstory and I

00:22.800 --> 00:30.080
will be sure to tell you all about it and then of course some of us know Mark has been

00:30.080 --> 00:36.720
personally a personal session of mine for a few decades but I'm going to attempt at having

00:36.720 --> 00:42.160
got brief introduction to Mark which is impossible because it's extremely complicated and then I'm

00:42.160 --> 00:48.880
going to go and say how it implemented why I discovered the YB4 but like what is the principle

00:48.880 --> 00:55.280
between the implementation and I can you go towards implementing something like this and then

00:55.280 --> 01:03.520
the lesson learned okay let's start so the backstory this is not my first time and I present

01:03.520 --> 01:09.600
to this bedroom I think it was in 2016 and 2018 and presented my macocerna which was called

01:09.600 --> 01:16.720
Moujahak which was all John interface exported was such as the vice diver that you can see the

01:16.720 --> 01:24.080
presentation for the reason why and after 2018 I realized that I needed to get rid of some code I was

01:24.960 --> 01:31.040
emotionally attached to which was mostly 32 bit and it is 6 and it okay I actually need to

01:31.040 --> 01:38.720
port it to modern hardware and so I started this project called nooks so nooks became in the end like

01:38.720 --> 01:43.840
I cannot put a type in framework so it's something that is extremely portable and it's meant to

01:44.960 --> 01:50.080
allow me to put a type kernel which is something that I do in my spare time when I don't do synthesizers so

01:52.320 --> 01:58.240
okay the original motivation was that and when I designed this framework first of all I make it

01:58.240 --> 02:07.360
portable so I now it works in I36 and this 64 it is 564 and originally was meant to run Moujahak

02:07.440 --> 02:12.880
which was a very simple kernel I made it extremely simple for a reason I didn't believe in the mix

02:12.880 --> 02:19.200
between fork and threads so I made it just I implemented forks I didn't implement user threads

02:20.160 --> 02:26.560
and nooks essentially has this implementation if you're interested in about nooks tomorrow I will

02:26.560 --> 02:33.360
have a talk in the eye dev room and I will have to explain more in details over there why I did or

02:33.360 --> 02:37.040
do the architecture of nooks so if you're interested in that we should check that talk.

02:38.560 --> 02:45.360
Now yes so I essentially ported Moujahak to nooks it was quite easy because essentially it was the

02:45.360 --> 02:51.520
same underlying assumption about what a kernel should be and yes and now you know as a result

02:51.520 --> 02:56.800
I still haven't published a code but I got Moujahak for anyone who's interested that works in 64

02:56.800 --> 03:05.200
bit but in Intel and this 5. The problem with data is that I wanted to kind of publish nooks

03:05.200 --> 03:10.400
as a kernel development framework just to help people that just want to. It's an extremely simple

03:10.400 --> 03:15.520
to get a very simple kernel in nooks again tomorrow so it could be more about it essentially you

03:15.520 --> 03:22.480
define a mine a main function and so essentially entry function which is essentially like a event model

03:22.560 --> 03:29.200
it's a simple C file and you get a kernel that boots on SMP on modern hardware. I test it up to

03:29.200 --> 03:37.200
dual Z on with 40 calls so the problem is I wanted to test and test nooks to see how much can

03:37.200 --> 03:44.720
actually goes and really help me to make a big couple of kernels and I briefly consider doing

03:44.720 --> 03:49.920
a unique system far in our unique classical unique system but I say you know what there's

03:49.920 --> 03:54.880
something that is more complicated than a unique kernel way more complicated and that is mark

03:55.600 --> 04:01.200
and so why mark is more complicated so I want for the hardest thing right and well the mark

04:01.920 --> 04:07.520
normal implementation is I heavily use of kernel threads and in nooks I do not support kernel

04:07.520 --> 04:13.280
threads so I wanted to see can I actually statement you will know idea when you'll get out of it right

04:13.920 --> 04:22.560
like pages and pages of mysterious locking out so I actually was very curious why is it written

04:22.560 --> 04:28.320
like this it's that the only way can be written you know I lack you feminism and so I shouldn't

04:28.320 --> 04:35.760
probably say what I think and also there's another reason that I realized in 2025 is the 20th anniversary

04:35.760 --> 04:43.120
of my stomach branch which was a clone of new mark that I presented in 2005 actually I think

04:43.120 --> 04:50.000
it was November 2005 the stomach sorry I had a hard meeting in Madrid and essentially it was

04:50.000 --> 04:54.320
a bit of a crazy stuff but essentially I wanted I tried to solve the problem of the lack of

04:54.320 --> 05:00.800
diversity in the new herd so I plotted a common interface so I could use a skate inside the new

05:00.800 --> 05:06.880
herd instead of doing what I was doing but anyway this is actually history now so there's a personal

05:06.960 --> 05:13.840
and I'm finished business with Mark so when I wanted to to bought Mark I was thinking how can

05:13.840 --> 05:21.600
I do this? Mark was famous for being portable so there's a very well well-defined interface

05:21.600 --> 05:27.440
to implement to port noks to import Mark to an architecture and though I could have ported

05:27.440 --> 05:33.280
noks as an architectural part and the only thing that I actually needed to do which was very weird

05:33.280 --> 05:40.160
was to implement canal threads in noks which I can do but felt a bit unnatural and then there was

05:40.160 --> 05:48.560
the hardest way the one where I can actually implement it from scratch it's a bit insane but the

05:48.560 --> 05:54.400
two of this had enough personal curiosity about Mark and why was it in this way and all the things

05:54.400 --> 06:01.600
I said before I said you know what actually I really like understanding things by implementing it so

06:01.680 --> 06:07.280
it's a bit insane but I could probably try that that I repeat like this is the question that I had

06:09.280 --> 06:14.800
those are completely hard to be complicated and difficult to read and okay yes we all know that Mark

06:14.800 --> 06:20.080
was a pioneer in many modern or I said yes what kind of choice it would have been made today

06:20.080 --> 06:25.360
it's it's much easier after you implement to think about them because you have to solve the problems

06:26.160 --> 06:34.960
solved it's of course I chose this now I'm going to try to I can one cool talk for

06:34.960 --> 06:39.760
hours about this so by brief I need to be I'm going to skip a lot of details I'm going to simply

06:39.760 --> 06:44.560
fire a lot and if you say that I say something wrong I'm probably just simplifying over it just

06:44.560 --> 06:52.640
pretty wrong right so what Mark was famous for it was the first thing that was it was very

06:52.640 --> 06:58.080
famous for this IPC everything was a message pass and it's not a message passing as you find

06:58.080 --> 07:05.680
modern kernels so in the in the documentation they say that they they push for a client server

07:05.680 --> 07:12.320
architecture except in the code they call it a user server architecture which becomes complicated

07:12.320 --> 07:17.840
because there are three ways to kind of messages the first is user space to use a space or you have

07:17.840 --> 07:23.680
a server user space and a user user space you send messages but you can have a kernel server and

07:23.680 --> 07:29.040
so the kernel server the user send a message to the kernel which that's how you get that's how you get

07:29.040 --> 07:35.280
services but of course there's the most annoying definition ever which is kernel user which

07:35.280 --> 07:41.920
of course it means that the kernel request services or send notification to our user and so the server

07:41.920 --> 07:46.960
is in user space and the user is in kernel space. Anyway once you understand that everything

07:47.040 --> 07:55.200
sort of fine but in my make my make branch I change I also allow kernel user to be the

07:55.200 --> 08:06.080
fine as kind of client. Now write and send once is it simple no it's way more complicated than that

08:06.080 --> 08:14.480
because the send write are actually counted the send count can only be one and when I send a

08:14.480 --> 08:19.120
message the easier way to think it's like when I send a message essentially I am giving the right

08:19.120 --> 08:24.720
to the server back and so the left count change well for second clone the right so it's it gets

08:24.720 --> 08:29.360
a bit more complicated but this is the idea and then there's a thing called port sets which are

08:29.360 --> 08:36.480
very annoying to implement in which essentially I can collect a lot of port lights together and so

08:36.480 --> 08:42.720
with a single receiver I can see from multiple ports. So this is when I said that the appc

08:42.880 --> 08:48.400
is nice but this is how it becomes and so you can imagine that then you can have port rights for

08:48.400 --> 08:54.560
kernels services the kernels doesn't really care about rights to use other stuff like this.

08:56.480 --> 09:04.240
Now let's get more complicated shall we? Mark of course introduce our interface definition language

09:04.240 --> 09:10.000
to just call make and of course you can use it on server code again think use it as client

09:10.320 --> 09:16.560
and yeah so these are the works I mean this distance quite say and actually there's an interface

09:16.560 --> 09:22.240
definition there's a musical and some may mark into make generates from the interface definition

09:22.240 --> 09:27.760
I use a code and a server code and so you know like I call it from here and the interface

09:28.480 --> 09:32.880
goes on the other side so whatever I link the server code that's what I'm going to get to think

09:33.280 --> 09:41.120
of course think about this when I have a kernel server the server co-generated by make will

09:41.120 --> 09:46.800
be compiling kernel when I have a kernel user code the user co-generated by make which is a

09:46.800 --> 09:55.680
tool user space tool will be compiled in kernel as well. Now did I say that is oh yeah so I

09:55.680 --> 10:01.360
miss some very important things here kernel defined message so essentially like the message that

10:01.440 --> 10:06.560
the make generates because essentially from kernel code I need to to create a message that then

10:06.560 --> 10:15.040
get sent the the message needs to be known as specific kernel kind of dependent function

10:16.080 --> 10:23.680
why is that because the kernel might need to pass the message so messages are typed in mark

10:24.640 --> 10:32.720
and so for example the message adder will we will link to the port the port write ID of the

10:32.720 --> 10:38.560
sender and possibly other play port and then the value stipes now the two types of messages that

10:38.560 --> 10:44.560
I can send so you know minimum minimum case scenario the kernel when you save a message only need to

10:44.560 --> 10:50.160
pass the header but there's this thing called complex messages and it does need to be passed

10:50.160 --> 10:56.960
all of them even the body of the message because they can contain other range I can just say okay

10:56.960 --> 11:02.320
just move this code copy this code to this process and I've touched this memory to the messages

11:03.120 --> 11:08.160
I can send port write this is our right help it is essentially the capability system of

11:08.160 --> 11:14.080
markets implemented I can send port write support and sometimes I can just directly say okay

11:14.080 --> 11:20.160
I'd apply to this port and this is a port name and stuff like this so what does it mean is that

11:20.160 --> 11:27.040
the fact that the kernel the mix needs to find messages that are needs to make them to find

11:27.040 --> 11:32.800
a message that are actually need to be understood by the kernel it means that pretty much

11:32.800 --> 11:38.160
make and the kernel are tightly coupled so when you implement your own kernel you need to be sure

11:38.160 --> 11:43.920
to implement your own megas well and system that essentially do the physical memory cache

11:44.000 --> 11:49.920
and it just tell the page please save this page so I can create this memory complication that

11:49.920 --> 11:56.000
in reality there are two more complication if you want to know the what I discovered is just

11:56.000 --> 12:00.560
one coupon write mechanism there are three of them and the most annoying one is copy known

12:00.560 --> 12:05.760
which despite the name it's actually copies everything so actually when you switch between

12:05.760 --> 12:10.640
delay to copy normal we use copy known all the page that has worked out needs to be swapped in

12:10.640 --> 12:16.400
by the kernel and then swap it out again and copy and then swap that on both things this is

12:16.400 --> 12:21.040
very annoying and it's only using a 1994 commit by new hard so I'm not going to implement that

12:21.040 --> 12:27.920
shit so oh there's another complication of course you can read that out and not going to do that

12:28.880 --> 12:33.600
so how did that implement mark you know so I hope I convinced you that this thing is complicated

12:33.600 --> 12:38.480
unless they complicated what I wanted to do is avoid looking at the Microsoft code

12:38.480 --> 12:46.640
actively because I wanted to I didn't want to be primed by the mark implementation not so because

12:46.640 --> 12:50.800
I wanted to present this I see what the code look like and what they want to be primed so

12:50.800 --> 12:55.360
the first thing I wanted to see okay the two most complicated system are IPC and VM so

12:57.760 --> 13:02.400
I wanted to implement one first and then the other but of course I can't do that because in

13:02.400 --> 13:06.960
mark when you send a message to my service part of the other space which can be mapping many

13:07.120 --> 13:11.600
VM objects so you can imagine what happened as I said you know this is insane so I

13:11.600 --> 13:18.800
essentially create a special kernel buffer and it's shared memory between kernel user and just send a

13:18.800 --> 13:26.000
message and these are these so allow me to implement IPC first and VM later of course there's

13:26.000 --> 13:34.240
a big limitation that there's a big limitation that the messages are now limited in maximum

13:34.240 --> 13:39.360
size because of course in mark the message that password kernel can be 100 gigabytes who cares right

13:40.080 --> 13:45.520
so anyway I did that and there's a bit of problem in MIG so do the things that I did the mark

13:45.520 --> 13:50.400
is essentially I hit the module and I think this is more expected by this picture so I got the

13:50.400 --> 13:55.440
kernel that only defined kernel object in the interactions they got a kernel module and I leave

13:55.440 --> 14:01.040
module that essentially the MIG output for the kernel interfaces and then of course I got the

14:01.120 --> 14:06.720
but of style that is highly dependent to this so what I have is a way to create multiple

14:06.720 --> 14:12.400
personal inside mark so that we can have a marked thing personality and then having the

14:14.080 --> 14:20.480
you know having various things and testing various things so the way I implemented the IPC

14:20.480 --> 14:26.320
is that I simply have like an external format which is the crazy things that I just got before

14:26.400 --> 14:32.560
and then essentially like I solved the things I solved the messages by by you know checking the

14:32.560 --> 14:39.520
things since only saving the rev component internally and actually this is very fast apparently

14:40.080 --> 14:45.520
and this is the way I implemented the VM I could spend 20 minutes on this alone and I'm gonna do it

14:45.520 --> 14:50.880
but this is all implemented so I'm very proud of that so I essentially have a clock algorithm that

14:50.960 --> 14:56.880
I commit page and this is a layer which in particular is basically the VM object with all the

14:56.880 --> 15:04.160
shadowing part the cache object just be sure to essentially tells the VM object I never seen this page

15:04.160 --> 15:09.520
I marked this page before and the page is page out and so you know the cache object on the page

15:09.520 --> 15:14.560
take longer than marked in the VM object the memory cache essentially the pfn and the clock

15:14.560 --> 15:21.560
the then just the has nothing to do with this