BSD Driver Harmony
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61398 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023376 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Device driverCollaborationismCurve fittingFunctional (mathematics)Device driverCodeMacro (computer science)Wechselseitiger AusschlussDeclarative programmingMereologyAreaBitDifferent (Kate Ryan album)Interface (computing)EmailVideo game consoleBus (computing)SoftwareLattice (order)Communications protocolQueue (abstract data type)Object-oriented programmingPhysical systemComputer hardwareVariable (mathematics)Data transmissionSoftware bugMotion captureFrustrationDevice driverStack (abstract data type)Matching (graph theory)EvoluteLetterpress printingIntrusion detection systemMathematicsArithmetic progressionTouchscreenFitness functionProgrammierstilElectronic mailing listSystem callData structure1 (number)Heat transferPairwise comparisonPlastikkarteRight angleStandard deviationKernel (computing)CASE <Informatik>Fluid staticsComputer programmingMultiplication signMachine codeSlide ruleComputer configurationWordMenu (computing)PhysicalismFigurate numberPoint (geometry)Task (computing)Web pageSimilarity (geometry)Process (computing)Open setFreewareType theoryStreaming mediaInheritance (object-oriented programming)Instance (computer science)Online helpFilm editingDescriptive statisticsPrototypeDisk read-and-write headRing (mathematics)Computer virusComputer animation
08:26
Execution unitCodeChi-squared distributionCondition numberWhiteboardSimulationDivision (mathematics)Gamma functionView (database)Multiplication signWikiPhysical systemDevice driverSoftwareComputer fileConstraint (mathematics)File archiverDifferent (Kate Ryan album)1 (number)Group actionProcess (computing)Standard deviationLatent heatInterface (computing)FreewarePrototypeCodeData structureInstance (computer science)Address spaceContext awarenessPlastikkarteMathematicsForcing (mathematics)BlogFlow separationDirection (geometry)Level (video gaming)Taylor seriesFigurate numberFunctional (mathematics)WhiteboardOrder (biology)Device driverSpacetimeComputer programmingBitDatabaseType theoryGoodness of fitSoftware developerProjective planeCASE <Informatik>Complex (psychology)DigitizingOpen setAbstractionEmailSoftware bugElectronic mailing listCategory of beingProcess capability indexGodLibrary (computing)System callExpressionWritingComputer animationLecture/Conference
16:47
Program flowchart
Transcript: English(auto-generated)
00:05
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,
00:21
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
00:43
about how we can work together on BSD drivers. Speaking 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
01:02
for different hardware, showing how, for instance, on FreeBSD for sound cards, you have SoundHDA. On OpenBSD, you have Azalea, then HD audio on NetBSD now. And so you have sometimes a driver missing in one BSD, not in the other. They have different names. Sometimes history, which merges, goes somewhere,
01:23
then patches come back, go. 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
01:41
from the other BSDs and the 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 it feels a bit sometimes like a rabbit hole, I would say. So we have a collection of drivers with different history,
02:02
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 FreeBSD.
02:20
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,
02:40
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 netBSD, it's a bit simpler. Actually, one less header, fewer functions
03:00
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 openBSD. Oops. There's no manual page for driver on openBSD. So hi, Stefan. You want to volunteer? Read the code.
03:21
He said read the code. Yeah, gladly. You couldn't be more on queue. We're going to look at UMB, which comes from openBSD, actually. So this is the manual page from openBSD for UMB. Our documentation is usually very good. So that was just a joke.
03:44
So basically, the UMB driver is about a USB network card, which does LTE slash 4G support on the USB bus using the MBEAM protocol. So it's actually a standard protocol for many cards across vendors to support cards
04:03
from Dell, Ericsson, Sierra wireless, quite a few, and so on. And I actually happen to have ported the code from openBSD to netBSD, where I heard it works. And then I also did it for freeBSD.
04:20
And this is actually a side-by-side comparison of the freeBSD code on the left and the netBSD code on the right. I didn't put openBSD here because it's actually very, very close to the netBSD code, which is good news for the driver harmony. So just keep in mind that it's also an openBSD.
04:43
But anyway, to prove my point, the netBSD port is actually also quite close to the freeBSD one. But there are some differences. So again, sorry if it's not super readable here in the room.
05:01
Probably on the stream, then it looks less good. And I prefer to 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.
05:20
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 parts are identical. The purple are changes.
05:42
So then, except for some debugging variables here, it's very similar at the top of the driver with the variables. And then we reach the method descriptions, the prototypes. They're actually very similar, except on netBSD. Or actually, in the original openBSD driver,
06:01
there was a redefinition of static. So I followed the coding style that I found in original driver or in FreeBSD, in this case. So that's really the only major difference in most prototypes. And it goes on and on. Then on FreeBSD, you have one big difference
06:21
on the USB stack, where the definitions for the transfers are in a variable. So you have the bulk ones in and out, like transmission and reception. Then we continue the function for probing fits in one screen.
06:40
So here, as we saw in the manual page, it's called probe. And netBSD is called match. Otherwise, it does mostly the same. There's a few differences in the USB stack. So get interface descriptor, find iDesk. But it's actually more or less the same. Then that's the code to attach. It's a bit more involved.
07:01
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.
07:21
So the USB stack is quite similar, but also different. So here, you have get interface descriptor. Here, you have something else, which is the same. Get interface descriptor again. The naming conventions are a bit different. But overall, it's very similar.
07:42
So I can keep scrolling. I hope you get the idea. Basically, we reached 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.
08:03
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 the USB stack behaves the same way, there are minor differences.
08:21
Like on FreeBSD, here, I had to hold the mutex. And the netBSD 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.
08:41
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,
09:00
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.
09:23
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.
09:42
We could separate the BSD-specific code, like free BSD-specific, open BSD-specific, net BSD-specific from the driver-specific code. Would be 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.
10:01
We could change names. One great thing about BSDs is that the systems are developed as one consistent whole. And there are usually fixed releases for the whole system. So this is maybe easier to do that in the BSD world than in the Linux world, for instance, and so on and so forth. Outside of the driver code itself,
10:22
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,
10:43
or sometimes not. So just showing ideas. We could also share Git commits if we would have a bigger, closer convergence. And if we would all switch to Git, there are mirrors too.
11:02
Or there is God. 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 are called BSD drivers or BSD driver harmony.
11:21
So I created a mailing list, if you want to join, where we could discuss if the mailing list is the best thing to have. We are in 2023, so we could also have a Discord or something like that, whatever the cool kids do nowadays. Or anyway, I set up some archives if you want to have discussions on the mailing list.
11:41
Maybe we could set up an RAC channel. Maybe we could set up a Wiki somewhere to specifically document how to best write portable code across the different BSDs. Maybe we could discuss funding. That would be very welcome. And basically, to wrap up, now, of course,
12:03
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.
12:21
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 code together. You can reach me at this address. I'm at NetBSD, actually. I'm also on the NetBSD financials board, so it's easy for me also to forward ideas
12:43
in the higher spheres, across the different committees we have. We have many committees. And then thanks for listening. I will welcome your questions, also online. And hope it resonates for you.
13:08
Yes? How friends, they can put all three in there, so that you have a per-level, per-new interface.
13:23
But then they have four different states. Then you have four interfaces. 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 BSDs? Then Taylor said, then you have a force interface, which is kind of true.
13:41
We all remember the XKCD. I will just create a new standard, because there's too many standards. I don't think it's so difficult, necessarily, because, as mentioned, a lot of drivers are actually very similar. The subsystems are very similar. And I just learned this morning that, in some cases,
14:00
there are ODF expression layers which are coming, like in FreeBSD, from Juniper, if I'm correct. So maybe this is something which could be used, also, across the other BSDs, converting code for that. What did you say about Juniper? That they are now pushing a new abstraction layer in FreeBSD for their network drivers and network cards. So it's already?
14:23
I think they're not really having the other BSDs in mind. But this is something which would maybe help the FreeBSD drivers, which would be then converted, to be converted, in turn, to the other BSDs. So maybe it's going to happen, de facto. It's one direction we can push for.
14:41
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.
15:20
So you're not really asking a question, but reminding us, basically, that some drivers or some subsystems have very specific constraints on different BSDs. 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 a typed context.
15:40
Sometimes not. So yeah, for sure. Time is up also for questions. Can we squeeze one more? Christophe?
16:02
So you were just saying that for the stream, we could push for, can you repeat? Yeah. Call and call kind of library and use that in all the hours about drivers and fix a lot of bugs, by the way.
16:20
Deleted half the code, next half the bugs in. 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. OK. I guess we'll stop here for now.
16:41
And let the next speaker speak in three minutes. Thank you.