Hi everyone, thank you for joining, thank you for liking BSD and hopefully I will try
to encourage you to help developing BSD so let's get started.
So the program for my discussion for which I have 15 minutes is to go through 45 slides
so hang tight, just kidding but I will start with a bit of background information, compare
some device driver codes so we can have an idea how it looks between the different BSDs,
call for help and try to send a few ideas out about how we can work together on BSD drivers.
Anything of which, what about BSD drivers? Well, sadly the lighting doesn't allow me really
to show much so basically I'm gathering the list of different drivers for different hardware
showing how for instance on free BSD for sound cards you have sound HDA, on open BSD you
have Azzelia, then HD Audio on net BSD now and so you have sometimes the driver missing
in one BSD not in the other, they have different names, sometimes history which mergers go
somewhere then patches come back, some areas are more developed in one BSD over another
like TV capture or sometimes Wi-Fi so it's a bit frustrating in a way that we have this
awesome hardware support and at the same time not every BSD benefits always from the other
BSDs and progress they make or one bug is fixed in one and not in the other so to summarize
and good morning, it's a bit of a mess, drivers everywhere but feels a bit sometimes like
rabbit hole I would say so we have a collection of drivers with different history, some in
common, some with different names, evolution is not consistent across the different BSDs
but thankfully there is documentation, let's have a look at the differences between the
different systems so this is the manual page for driver on free BSD so as you can see you
have a few system headers, kernel headers in this case, some functions which should
always be implemented probing, attaching, detaching, some throbbing and twiddling whatever
that means, some data structures with references to the methods for attaching, probing and
so on and then a declaration for the driver for the kernel to find it, another macro here
gathering, putting everything together so looks pretty nice and clear to me but then
if you look on met BSD it's a bit simpler actually, one less header, fewer functions
which are documented here or mentioned here at least then just a single macro to attach
all the bits together and declare it for the system then you have open BSD, oops, there's
no manual page for driver or an open BSD so hi Stefan, you want to volunteer, he said
read the code, yeah gladly, you couldn't be more on Q, we're going to look at UMB which
comes from open BSD actually, so this is the manual page from open BSD for UMB, the documentation
is usually very good so that was just a joke, so basically the UMB driver is about a USB
network card which does LTE slash 4G support on the USB bus using the MBIM protocol so
it's actually a standard protocol for many cards across vendors to support like cards
from Dell, Ericsson, Sierra wireless, quite a few and so on and I actually happened to
have ported the code from open BSD to net BSD where I heard it works and then I also
did it for free BSD and this is actually a side by side comparison of the free BSD code
on the left and the net BSD code on the right, I didn't put open BSD here because it's actually
very very close to the net BSD code which is good news for the driver harmony so just
keep in mind that it's also an open BSD but anyway to prove my point the net BSD port is
actually also quite close to the free BSD one but there are like some differences so
again sorry if it's not super readable here in the room probably on sorry actually on
the stream and it looks less good and I prefer to like show my face than the code no I'm
just kidding maybe we should have planned better no actually we spent some time figuring
which different options but right now it's the best compromise but to summarize of course
the license text stays the same the system headers are quite similar some are in common
some are necessary in one over the other then if we keep scrolling down basically the black
part are identical the purple are changes so then except for some debugging variables
here it's very similar at the top of the driver with like the variables and then we reach
the the method descriptions the prototypes they're actually very similar except on net
BSD we or actually the original open BSD driver there was a redefinition of static so I followed
the coding style that I found in original driver or in free BSD in this case so that's
really the only major difference in most prototypes and it goes on and on then on free BSD you
have one big difference on the USB stack where the definitions for the transfers are in a
variable so you have like the bulk ones in and out like transmission and reception then
we continue the function for probing fixing fits in one screen so here as we saw in the
manual page it's called probe and net BSD is called match otherwise it does mostly the
same there's a few differences in the USB stack so get interface descriptor find I desk
but it's actually more or less the same then that's the code to attach it's a bit more
involved but of course some variables are in common because it's the same code originally
then quite a few changes but it's actually the same thing that is being done looking
up USB device IDs on both sides some setup the printing for the console so the USB stack
is quite similar but also different so here you have get interface descriptor here you
have something else which does the same yeah get interface descriptor again the naming conventions
are a bit different but overall it's very similar so I can keep scrolling I hope you
get the idea basically we wish the detaching code same thing again here we are the driver
of course is the part where there's the most similarity because it doesn't have to be specific
for each BSD so there's a lot more black as a consequence we keep going I'm not going
to show the whole driver of course don't worry another thing which is an important thing
to have in mind is that for instance even when the code is the same and USB stack behaves
the same way there are minor differences like on free BSD here are to hold the mutex and
the net BSD for a similar call at task I didn't have to so you have to be wary of each specific
requirement of the underlying stack that you're using on each BSD some functions can be called
in interrupt context some cannot some require mutex some don't so basically it's what's
going on so my dream is to have one driver API for every BSD so that we can share all
the code but in reality I don't know if there is any chance to get to that however it would
be great I think if we could go towards this and have more convergence take steps to get
closer maybe both on the community level as much as on the programming level with the
driver code so I'm showing some ideas here today what can be done in most BSDs the drivers
fit in one file usually for the more complex ones there's sometimes a few more files but
if we would change this convention we could have separate files maybe put variables which
would be then the same between the different BSDs in separate files so we can easily merge
that when there are changes in one or the other we could separate the BSD specific code like
free BSD specific open BSD specific net BSD specific from the driver specific code maybe
another idea we could go towards abstraction layers which is not always great but maybe
some prototypes some variable types could be extracted the same way we could change
names when great thing about BSDs is that the systems are developed as one consistent
wall and there are usually fixed releases for the whole system so this is maybe easier
to do that in the BSD world and in the Linux world for instance and so on and so forth outside
of the driver code itself we have the system databases which could be unified a bit more
like the PCI and USB IDs which are sometimes different between the different BSDs mostly
the same but some names change including for register values in some drivers the driver
names also are sometimes different for the same driver or at least historically or sometimes
not so just showing ideas we could also share Git commits if we would have a bigger like
a closer convergence and if we would all switch to Git there are mirrors too or there
is got you can stay for Stefan's talk to learn more about that so basically I'm trying
to set up a new exchange space for this initiative which I called BSD drivers or BSD driver harmony
so I created a mailing list if you want to join what we could discuss if the mailing list
is the best thing to have we are in 2023 so we could also have like a discord or something
like that that whatever the cool kids do nowadays or anyway I set up some archives if you want
to have discussions on the mailing lists maybe we could set up an RSC channel maybe
you could set up a weekly somewhere to specifically document like how to best write portable code
across the different BSD's maybe we could discuss funding it would be very welcome and
basically to wrap up now of course each BSD has its own community but maybe we could try
to get closer even though we have the major conferences in here the common dev room would
be great maybe outside of the conferences to create a space for this so as mentioned
kind of drivers can be challenging they are quite close similar but also different so
anyway I hope this is worth the effort and that you will join participate and that we
can write BSD codes together you can reach me at this address I'm at net BSD actually
I'm also in the net BSD financials board so it's easy for me also to forward ideas in
the higher spheres across the different committees we have many committees and then thanks for
listening I will welcome your questions also online and hope you hope it resonates for
you yes yes yeah
so the question is if I summarize it I guess how difficult is it to make an abstraction
layer which would work on those three BSD's then Taylor said then you have a force interface
which is kind of true we all remember the XKCD I will just create a new standard because
there's too many standards well it's I don't think it's so difficult necessarily because
as mentioned a lot of drivers are actually very similar the systems are very similar
and I just learned this morning that in some cases there are already abstraction layers
which are coming like in free BSD from Juniper if I'm correct so maybe this is something which
could be used also across the other BSD's converting code for that that they are now
pushing a new abstraction layer in free BSD for the network drivers network cards yeah
I think they're not really having the other BSD's in mind but this is something which
would maybe help the free BSD drivers which would be then converted to be converted in
turn to the other BSD's so maybe it's going to happen the facto it's one direction we
can push for that's why I want to talk to developers across the different BSD projects
I contacted people on the open BSD and free BSD side already and they are really receptive
to the idea the issue is to spend the time and probably to make it happen yeah so you
are not really asking a question but reminding us basically that some drivers or some subsystems
have very specific constraints on different BSD's so the abstraction layer will have
to keep this in mind really carefully like what I mentioned sometimes you need a mutex
sometimes you need you can do something in interrupt context sometimes not so yeah for
sure time is up also for questions not can we squeeze one more or yeah so you were just
saying that for the stream we could push for yeah yeah so in that BSD we've been pushing
for USB net unifying drivers on the USB network category to make them more the same we found
many bugs and it helped get them all closer together yeah okay I guess we'll stop here
for for now and let the next speaker speak in three minutes thank you