[00:00.000 --> 00:12.000] Hi everyone, thank you for joining, thank you for liking BSD and hopefully I will try [00:12.000 --> 00:18.300] to encourage you to help developing BSD so let's get started. [00:18.300 --> 00:24.560] So the program for my discussion for which I have 15 minutes is to go through 45 slides [00:24.560 --> 00:32.160] so hang tight, just kidding but I will start with a bit of background information, compare [00:32.160 --> 00:37.760] some device driver codes so we can have an idea how it looks between the different BSDs, [00:37.760 --> 00:48.480] call for help and try to send a few ideas out about how we can work together on BSD drivers. [00:48.480 --> 00:55.000] Anything of which, what about BSD drivers? Well, sadly the lighting doesn't allow me really [00:55.000 --> 01:03.400] to show much so basically I'm gathering the list of different drivers for different hardware [01:03.400 --> 01:09.320] showing how for instance on free BSD for sound cards you have sound HDA, on open BSD you [01:09.320 --> 01:15.960] have Azzelia, then HD Audio on net BSD now and so you have sometimes the driver missing [01:15.960 --> 01:22.480] in one BSD not in the other, they have different names, sometimes history which mergers go [01:22.480 --> 01:29.760] somewhere then patches come back, some areas are more developed in one BSD over another [01:29.760 --> 01:37.080] like TV capture or sometimes Wi-Fi so it's a bit frustrating in a way that we have this [01:37.080 --> 01:42.760] awesome hardware support and at the same time not every BSD benefits always from the other [01:42.760 --> 01:49.440] BSDs and progress they make or one bug is fixed in one and not in the other so to summarize [01:49.440 --> 01:57.840] and good morning, it's a bit of a mess, drivers everywhere but feels a bit sometimes like [01:57.840 --> 02:01.880] rabbit hole I would say so we have a collection of drivers with different history, some in [02:01.880 --> 02:09.280] common, some with different names, evolution is not consistent across the different BSDs [02:09.280 --> 02:13.840] but thankfully there is documentation, let's have a look at the differences between the [02:13.840 --> 02:20.960] different systems so this is the manual page for driver on free BSD so as you can see you [02:20.960 --> 02:25.760] have a few system headers, kernel headers in this case, some functions which should [02:25.760 --> 02:30.600] always be implemented probing, attaching, detaching, some throbbing and twiddling whatever [02:30.600 --> 02:38.880] that means, some data structures with references to the methods for attaching, probing and [02:38.880 --> 02:46.520] so on and then a declaration for the driver for the kernel to find it, another macro here [02:46.520 --> 02:53.040] gathering, putting everything together so looks pretty nice and clear to me but then [02:53.040 --> 03:00.280] if you look on met BSD it's a bit simpler actually, one less header, fewer functions [03:00.280 --> 03:06.640] which are documented here or mentioned here at least then just a single macro to attach [03:06.640 --> 03:13.200] all the bits together and declare it for the system then you have open BSD, oops, there's [03:13.200 --> 03:21.920] no manual page for driver or an open BSD so hi Stefan, you want to volunteer, he said [03:21.920 --> 03:30.640] read the code, yeah gladly, you couldn't be more on Q, we're going to look at UMB which [03:30.640 --> 03:38.000] comes from open BSD actually, so this is the manual page from open BSD for UMB, the documentation [03:38.000 --> 03:47.720] is usually very good so that was just a joke, so basically the UMB driver is about a USB [03:47.720 --> 03:56.840] network card which does LTE slash 4G support on the USB bus using the MBIM protocol so [03:56.840 --> 04:02.480] it's actually a standard protocol for many cards across vendors to support like cards [04:02.480 --> 04:10.480] from Dell, Ericsson, Sierra wireless, quite a few and so on and I actually happened to [04:10.480 --> 04:18.160] have ported the code from open BSD to net BSD where I heard it works and then I also [04:18.160 --> 04:23.880] did it for free BSD and this is actually a side by side comparison of the free BSD code [04:23.880 --> 04:30.120] on the left and the net BSD code on the right, I didn't put open BSD here because it's actually [04:30.120 --> 04:39.400] very very close to the net BSD code which is good news for the driver harmony so just [04:39.400 --> 04:48.560] keep in mind that it's also an open BSD but anyway to prove my point the net BSD port is [04:48.560 --> 04:55.760] actually also quite close to the free BSD one but there are like some differences so [04:55.760 --> 05:05.080] again sorry if it's not super readable here in the room probably on sorry actually on [05:05.080 --> 05:10.360] the stream and it looks less good and I prefer to like show my face than the code no I'm [05:10.360 --> 05:18.600] just kidding maybe we should have planned better no actually we spent some time figuring [05:18.600 --> 05:24.440] which different options but right now it's the best compromise but to summarize of course [05:24.440 --> 05:29.920] the license text stays the same the system headers are quite similar some are in common [05:29.920 --> 05:37.520] some are necessary in one over the other then if we keep scrolling down basically the black [05:37.520 --> 05:44.880] part are identical the purple are changes so then except for some debugging variables [05:44.880 --> 05:49.800] here it's very similar at the top of the driver with like the variables and then we reach [05:49.800 --> 05:56.880] the the method descriptions the prototypes they're actually very similar except on net [05:56.880 --> 06:05.120] BSD we or actually the original open BSD driver there was a redefinition of static so I followed [06:05.120 --> 06:11.480] the coding style that I found in original driver or in free BSD in this case so that's [06:11.480 --> 06:19.360] really the only major difference in most prototypes and it goes on and on then on free BSD you [06:19.360 --> 06:26.000] have one big difference on the USB stack where the definitions for the transfers are in a [06:26.000 --> 06:33.680] variable so you have like the bulk ones in and out like transmission and reception then [06:33.680 --> 06:41.720] we continue the function for probing fixing fits in one screen so here as we saw in the [06:41.720 --> 06:46.720] manual page it's called probe and net BSD is called match otherwise it does mostly the [06:46.720 --> 06:53.200] same there's a few differences in the USB stack so get interface descriptor find I desk [06:53.200 --> 07:00.040] but it's actually more or less the same then that's the code to attach it's a bit more [07:00.040 --> 07:05.960] involved but of course some variables are in common because it's the same code originally [07:05.960 --> 07:09.800] then quite a few changes but it's actually the same thing that is being done looking [07:09.800 --> 07:21.520] up USB device IDs on both sides some setup the printing for the console so the USB stack [07:21.520 --> 07:26.040] is quite similar but also different so here you have get interface descriptor here you [07:26.040 --> 07:35.480] have something else which does the same yeah get interface descriptor again the naming conventions [07:35.480 --> 07:43.760] are a bit different but overall it's very similar so I can keep scrolling I hope you [07:43.760 --> 07:54.480] get the idea basically we wish the detaching code same thing again here we are the driver [07:54.480 --> 08:00.000] of course is the part where there's the most similarity because it doesn't have to be specific [08:00.000 --> 08:09.360] for each BSD so there's a lot more black as a consequence we keep going I'm not going [08:09.360 --> 08:14.800] to show the whole driver of course don't worry another thing which is an important thing [08:14.800 --> 08:19.040] to have in mind is that for instance even when the code is the same and USB stack behaves [08:19.040 --> 08:23.920] the same way there are minor differences like on free BSD here are to hold the mutex and [08:23.920 --> 08:31.480] the net BSD for a similar call at task I didn't have to so you have to be wary of each specific [08:31.480 --> 08:38.160] requirement of the underlying stack that you're using on each BSD some functions can be called [08:38.160 --> 08:44.800] in interrupt context some cannot some require mutex some don't so basically it's what's [08:44.800 --> 08:53.400] going on so my dream is to have one driver API for every BSD so that we can share all [08:53.400 --> 08:59.280] the code but in reality I don't know if there is any chance to get to that however it would [08:59.280 --> 09:06.680] be great I think if we could go towards this and have more convergence take steps to get [09:06.680 --> 09:13.120] closer maybe both on the community level as much as on the programming level with the [09:13.120 --> 09:21.280] driver code so I'm showing some ideas here today what can be done in most BSDs the drivers [09:21.280 --> 09:27.400] fit in one file usually for the more complex ones there's sometimes a few more files but [09:27.400 --> 09:33.840] if we would change this convention we could have separate files maybe put variables which [09:33.840 --> 09:38.280] would be then the same between the different BSDs in separate files so we can easily merge [09:38.280 --> 09:44.400] that when there are changes in one or the other we could separate the BSD specific code like [09:44.400 --> 09:49.880] free BSD specific open BSD specific net BSD specific from the driver specific code maybe [09:49.880 --> 09:57.480] another idea we could go towards abstraction layers which is not always great but maybe [09:57.480 --> 10:00.880] some prototypes some variable types could be extracted the same way we could change [10:00.880 --> 10:06.360] names when great thing about BSDs is that the systems are developed as one consistent [10:06.360 --> 10:12.280] wall and there are usually fixed releases for the whole system so this is maybe easier [10:12.280 --> 10:20.400] to do that in the BSD world and in the Linux world for instance and so on and so forth outside [10:20.400 --> 10:25.320] of the driver code itself we have the system databases which could be unified a bit more [10:25.320 --> 10:30.960] like the PCI and USB IDs which are sometimes different between the different BSDs mostly [10:30.960 --> 10:37.320] the same but some names change including for register values in some drivers the driver [10:37.320 --> 10:44.120] names also are sometimes different for the same driver or at least historically or sometimes [10:44.120 --> 10:54.320] not so just showing ideas we could also share Git commits if we would have a bigger like [10:54.320 --> 11:02.080] a closer convergence and if we would all switch to Git there are mirrors too or there [11:02.080 --> 11:10.760] is got you can stay for Stefan's talk to learn more about that so basically I'm trying [11:10.760 --> 11:20.800] to set up a new exchange space for this initiative which I called BSD drivers or BSD driver harmony [11:20.800 --> 11:26.120] so I created a mailing list if you want to join what we could discuss if the mailing list [11:26.120 --> 11:32.960] is the best thing to have we are in 2023 so we could also have like a discord or something [11:32.960 --> 11:38.680] like that that whatever the cool kids do nowadays or anyway I set up some archives if you want [11:38.680 --> 11:44.080] to have discussions on the mailing lists maybe we could set up an RSC channel maybe [11:44.080 --> 11:51.040] you could set up a weekly somewhere to specifically document like how to best write portable code [11:51.040 --> 11:57.840] across the different BSD's maybe we could discuss funding it would be very welcome and [11:57.840 --> 12:06.640] basically to wrap up now of course each BSD has its own community but maybe we could try [12:06.640 --> 12:12.120] to get closer even though we have the major conferences in here the common dev room would [12:12.120 --> 12:18.400] be great maybe outside of the conferences to create a space for this so as mentioned [12:18.400 --> 12:24.760] kind of drivers can be challenging they are quite close similar but also different so [12:24.760 --> 12:30.760] anyway I hope this is worth the effort and that you will join participate and that we [12:30.760 --> 12:37.960] can write BSD codes together you can reach me at this address I'm at net BSD actually [12:37.960 --> 12:43.440] I'm also in the net BSD financials board so it's easy for me also to forward ideas in [12:43.440 --> 12:49.480] the higher spheres across the different committees we have many committees and then thanks for [12:49.480 --> 12:58.000] listening I will welcome your questions also online and hope you hope it resonates for [12:58.000 --> 13:17.680] you yes yes yeah [13:17.680 --> 13:33.000] so the question is if I summarize it I guess how difficult is it to make an abstraction [13:33.000 --> 13:39.000] layer which would work on those three BSD's then Taylor said then you have a force interface [13:39.000 --> 13:44.160] which is kind of true we all remember the XKCD I will just create a new standard because [13:44.160 --> 13:49.400] there's too many standards well it's I don't think it's so difficult necessarily because [13:49.400 --> 13:54.960] as mentioned a lot of drivers are actually very similar the systems are very similar [13:54.960 --> 14:01.280] and I just learned this morning that in some cases there are already abstraction layers [14:01.280 --> 14:07.280] which are coming like in free BSD from Juniper if I'm correct so maybe this is something which [14:07.280 --> 14:14.680] could be used also across the other BSD's converting code for that that they are now [14:14.680 --> 14:23.680] pushing a new abstraction layer in free BSD for the network drivers network cards yeah [14:23.680 --> 14:27.920] I think they're not really having the other BSD's in mind but this is something which [14:27.920 --> 14:34.160] would maybe help the free BSD drivers which would be then converted to be converted in [14:34.160 --> 14:40.560] turn to the other BSD's so maybe it's going to happen the facto it's one direction we [14:40.560 --> 14:45.880] can push for that's why I want to talk to developers across the different BSD projects [14:45.880 --> 14:52.400] I contacted people on the open BSD and free BSD side already and they are really receptive [14:52.400 --> 15:21.240] to the idea the issue is to spend the time and probably to make it happen yeah so you [15:21.240 --> 15:27.360] are not really asking a question but reminding us basically that some drivers or some subsystems [15:27.360 --> 15:31.760] have very specific constraints on different BSD's so the abstraction layer will have [15:31.760 --> 15:36.720] to keep this in mind really carefully like what I mentioned sometimes you need a mutex [15:36.720 --> 15:42.120] sometimes you need you can do something in interrupt context sometimes not so yeah for [15:42.120 --> 16:03.000] sure time is up also for questions not can we squeeze one more or yeah so you were just [16:03.000 --> 16:25.720] saying that for the stream we could push for yeah yeah so in that BSD we've been pushing [16:25.720 --> 16:33.400] for USB net unifying drivers on the USB network category to make them more the same we found [16:33.400 --> 16:39.160] many bugs and it helped get them all closer together yeah okay I guess we'll stop here [16:39.160 --> 16:57.080] for for now and let the next speaker speak in three minutes thank you