Hello. My name is Paul Floyd. I'm here to talk to you about, as I said, a vaguined on
dragonfly net and open BSD. I'm a valgrain developer. I've worked mainly on free BSD, so I'm
not going to talk about that much today. My talk is going to be in two parts. First of all,
a brief overview of our grind. I only have 30 minutes, not 20 hours, so I can't
go to details. Second part will be on a vibramed on the BSDs. Our valgrain, it's mainly
new loan as a total for detecting memory faults for developers. It also has tools for
thread hazard detection and profiling. So when valgrain runs, what it's doing is taking a bunch
of instructions from what we call the guest. That's the test execution. It converts that into
intermediate representation, a bit like a compiler. It will instrument that to some optimization,
write it back to memory and execute it. This is the core of our grind. This is the schedule
that's doing this all the time. It's also a website. In this scheduling loop, there's also
doing other things. It has to handle how the end of these basic block occurs, has to handle
things like errors and system calls. That's really the core of our grind. Sounds easy.
Just one process. So the guest and host, both in memory, let's get very separate. But not
like GDB or LDB where you have P trace and two processes. A big thing here for developers is the
tool. It's always statically linked. We don't link with LBC. I sometimes say it's C minus minus,
there's no LBC. We do that because we don't want to have any conflict between the tool using
LBC and the guest using LBC. If you do a get-check out of our grind, you'll get about 840,000
lines of code. It's fairly big. About two thirds of that is the code and one third is test cases.
The big blue part here, Vx, is the synthetic CPU. And that covers all the platform that the
grind will run on. It's pretty big. I'm only going to talk about AMD 64 because that's
any platform that the BST run on. Free BST also runs on X86 and ARM 64. Good news here is that for
operating systems, the Vx code is very platform independent. I've worked on Free BST for five
or six years. I've made one change to Vx, but that was for a kind of memory fault, which on Linux it
pleases a segmentation fault on the BST's SIG bus. That's the only thing.
Bad news for us and in validering developers, we don't have enough people for all the CPU
features so we struggle a lot to do everything we. That's our problem. The big red part here is
core grind, so this is all the core services that Vagrin has to be provide. Like I said, no
lib C, so we have our lib C replacement there. Then there's all the glue that we have to provide
to make Vagrin look as though it's a real CPU and operating system. Next thing here, if you're
not familiar with it is the GDB server, which allows you to connect GDB to an executable
in Vagrin and debug it. It's all part of the core band. This part is very, very platform dependent
extremely. Just reference about 15,000 lines of code for Free BST in work.
Not huge, but a very big. The small little bits of the pie chart, most of those are the tools
and as you can see the tools are pretty small by comparison. Memcheck, the most well known tool,
about 3% of the source code. I'm not going to talk about much of the details about Vagrin running,
just a couple of things that are important. The one of the most important things is to start the
guest at Ctable. All this is happening in Vagrin. Vagrin is doing the loading and it'll run
LD.SO from within Vagrin. Here's an extract of a small hello world XC. That's the
object output on Free BST. You can see the load, that's the pieces of the file that need to be
loaded to memory to execute it. If you can't read the out information and look at it runs,
it's just going to tune it. It's good to finish. Similar to that, there's also the symbol table.
We need to read the out symbol table. If we can't read the out symbol table, then we can't do
things like replace malach or wrap the pie thread functions and lots of things work.
When libraries are being loaded, Vagrin decords all this. In theory, Vagrin does has a perfect memory
map of all everything's in physical memory. It doesn't work correctly, then we have problems
likely to be a crash or just mad results. The last one here is Dwarf the debug information.
If we can't read that, no source information in every message is and it becomes almost useless.
So two difficult things signals on threads. For signals, when there's a signal handler,
we have to make sure that the signal handler function doesn't run on its own on C2PU. We have to
hijack it and make sure it runs in Vagrin. Similarly for the secret term, that'll go back into Vagrin.
It's the same thing for P threads. We have to hijack the P thread to make sure it runs in Vagrin.
For signals, normally when Vagrin does run, it's masking all signals.
If it fall controls, when signal gets delivered. The exception to that is when there's a
blocking system called, for the guest, then we have to restore the guest signal mask. Do this
to some call, return to the system call and block that mask all signals again. There's lots of
juggling of system calls that are going on. It's very, very hard to get all this absolute
endemic direct. For the BSTs, I've seen quite a few problems with this. I've talked about
system calls. This is the biggest part of any platform for an OS. So we have to wrap every single
system call. So those of you who are not familiar with this system calls, 3BSD has 500 or so
typically run in the 500 reason. So it's a lot of code. Good news here. Most of this is just
boil code. This example from FBSD is the FF startup system call. You can see the print macro,
this is used for logging. Vagrin has many, many logging and tracing facilities. One of
these system calls. There are a few macros that we use for checking memory reads and writes.
There's a macro there for checking the arguments to be system call. And there are a couple
other things we do. There's tracking and checking file descriptors. And we have to do things like
flag when there's a blocking system call. Most of the time it's easy, but somewhat quite difficult.
So any system call involving threads, processes and querying CPU. That can be a lot more difficult.
That was the code to our tests. So this is my main measure of call to you for Vagrin,
the regression tests. Built into the source we have between six and eight and
depending on the CPU, tests, there's a not OS specific. Okay.
We'll make some free BSD. They have about 100 tests each. And I put in red here, right now,
drag and fly open and net BSD is zero tests with just for them. But in any feature that they have
on just for that platform is untested. So not good for the copy. Okay, a few more things we have
some bigger tests, one based on the GNU scientific library. And Linux only, shame we don't have
it in free BSD, LTP, the Linux test project. The last one there, we have a small performance test,
which we don't run very often because we know that flag went very slow.
Vagrin developers and Vagrin world, we're not very many, six people all working through part-time
on it, mostly it's red hat. So there's a team working on GDB, binary tools like
dwarf tools, elf tools and set that and Vagrin. So it's just spending some of that time on Vagrin.
At IBM, a couple of guys working on system 390 and PowerPC.
Men as me, I'm working in my spare time, mostly on the core green part and free BSD.
So for platforms that are covered by our, the Vagrin world, most of our stuff is on sourceware,
website, git and modern CI, our modern CI uses billbot.
Vagrin has been around for 23 years, so we've got a lot of history. For historical reasons,
our bugula is on KDE and sourceforge, if you remember that, it still has our mailing list.
Vagrin developers, we can access the GCC server farm and that's good for us because that gives us
a variety of operating systems, CPUs, and there are a few BSD machines on the way.
The last day there's our old Infra, for CI, that's a script you can put in, Chrontab,
which checks if there's been a git commit that day, checks out, build and sends an email to one of
them, mailing lists. BSD's net, all great I'm talking about, for Vagrin fly next in the
corner BSD, the source code I've looked at it was based on the free BSD fork, but all fairly old,
all from about five or six years ago. Vagrin fly, screen shot of a guy called Dan is GitHub site,
he did some work in 2021, hasn't been continue to don't think unfortunately.
When I looked at that source code, it looked very similar to the state of the free BSD source code
in Vagrin, when I started working on it, five or six years ago. Because Dragonfly is the closest
historically to free BSD, it should be the easiest to fix and to take the things that I've done on
free BSD and get to improve. Net BSD, so very hard to get to the source code, the wiki
refers to a defanct billionus website. I couldn't find the subversion thing anyway, package source
only refers to Linux, but what I'm going to talk about is I was contacted by some final year
students at the Western Washington University who were working on a family project to get net
BSD Vagrin working. Difficult for students for project. They did a good job, but unfortunately
they were a few very serious small problems causing those things to still fail. It's a shame
they didn't contact me at the end of their project to give it more help. I'm not going to talk about
all the bugs and fixes I've done, just a couple, so here's one hand fixed yet. Net BSD, this is
for a PIE executable, position independent executable. You can see the bottom line there,
Vagrin is complaining, it's trying to execute an instruction in readwrite anonymous memory.
That's totally wrong, that should be read execute and file mapped. So I don't know what the
cause of this is. Non-PIE executables run a K and PIE does work on 360 and Linux. It's not a fundamental
problem. Just one example of a little bag of effects. In the code there's lots and lots of
Defines, it's very platform dependent, this is operating system OS and CPU Defines. This function
recording the start up directory was missing the net BSD Define. The function had an old pointer
for the start up directory, which meant when things like log files or results files would
open at the end of execution, it would fail. Lots of things are failing because this one's small
error. Open BSD, this is the element in the room, this is the pin Cisco teacher. This was
adding in 7.5. This is the feature that is intended to limit system calls to LD.SO and Lipsy.
This is bad news for Vagrin because we need to make direct system calls. I've been talking about
system calls but a lot already. One solution would have been to do like Pearl and to use a dispatcher.
That's a bit of a non-starter. Not all Lipsy functions have rapid system calls so not
having is there. Lots of the biggest problem is you have to get Lipsy loaded and on free
BSD there are about 1,800 system calls even for Lipsy gets loaded so not possible.
The only thing I can see for Open BSD would be to implement a pin Cisco's table in Vagrin.
This is well beyond my abilities with Open BSD. Here's an example from a blog site I saw
using just two system calls. All the testing I've done on Open BSD was with 7.4. That's before
pin Cisco's was fully implemented. Now I'm getting out of the important things.
Pay attention. For comparison, FBSD and Illumos. So this is showing which is the current version
before I start at least. Whether it's in upstream or not, whether it's up to tree.
Whether you have a buying package or not and the quality of the regression test.
So pre-based in Illumos, up source, package is available and virtually all the regression tests work.
Dragonfly, I saw there was an attempt to get the binary package working but that
fizzled out for some reason. But two thirds of the test cases were passing.
So what I've done is I've rebased the code fixed a few things. I'm getting about 78% of the
test cases passing. Net BSD, I guess at the students they had a few small problems causing
lots of errors. I fixed those rebased and now I'm getting about two thirds of the test cases passing.
That's not brilliant, but it's good. Open BSD, a lot of small problems there. I haven't rebased
that code. I don't think anyone had ever run the regression tests because some of the components
haven't been ported to open BSD. I fixed those. I was only getting about 20% passes. I fixed a few
things. I'm now getting about 40%. That's the, if one thing you remember here is the two thirds
of a net BSD test passing. Those figures are a bit on the pessimistic side. The regression tests
have lots and lots of comparisons with core stacks which require a lot of filtering to get, say,
a few BSD calls back to look like a Linux core stack. And I haven't done that work for these platforms.
So real picture is a bit better. So for all the work I've done trying to fix a few things
and update things. I've created a GitHub repo. There's a 4.726 branch for each of those.
Another big question, where next? There's too much there for me to do all by myself to get them all
to be working fully. I need help from these communities. I need people to get in touch with me
to carry on the work. So I can help, I can advise, for like I said, I already spend a lot of time on
general vibrant and free BSD in the Linux. And I think free more. I also do some work on macOS as well.
It's just too much. So I need help. If you want to have vibrant working well on these platforms,
get into to me. We're old school. If you want to get in touch, mailing lists and IRC.
We also have some very open source people as well who don't like, particularly things like
Discord and things like that. Okay, a few more resources. I gave a talk four years ago during COVID.
It's always a very general thing. The last resource here at YouTube. There's a talk given by
good butcher's name, Mazda, Ubashi, at the European SDCon for 12 years ago.
I could recommend that. It was the one I would talk. So it's more technical and goes into a lot more detail.
And lastly, our website and the readmees and our gigs, so let's go. Thank you for listening.
Thank you.