The NetBSD Foundation has finalized the list of projects for this year’s Google Summer of Code. The contributors and projects are the following:

• Brian Schnepp - Raspberry Pi GPU Driver
• Arjun Bemarkar - inetd enhancements
• Piyush Sachdeva - Emulating missing linux syscalls
• Vihas Makwana - Introduce a new Wi-Fi driver
• Vivek Kumar Sah - Automating donor acknowledgement and information storage

The community bonding period has already started (from May 20) and it will last until June 12. During this time, the contributors are expected to coordinate with their mentors and community.

This will be immediately followed by the coding period from June 13 to September 4. After which, the contributors are expected to submit their final work, evaluate their mentors, and get evaluated by their mentors as well. Results will be announced on September 20.

For more information about the Google Summer of Code 2022 kindly refer to the official GSoC website.

We would like to express our gratitude to Google for organizing the yearly GSoC, and to The NetBSD Foundation mentors and administrators for their efforts and hardwork!

Let us welcome all the contributors to our growing NetBSD community!

The NetBSD Foundation has finalized the list of projects for this year’s Google Summer of Code. The contributors and projects are the following:

• Brian Schnepp - Raspberry Pi GPU Driver
• Arjun Bemarkar - inetd enhancements
• Piyush Sachdeva - Emulating missing linux syscalls
• Vihas Makwana - Introduce a new Wi-Fi driver
• Vivek Kumar Sah - Automating donor acknowledgement and information storage

The community bonding period has already started (from May 20) and it will last until June 12. During this time, the contributors are expected to coordinate with their mentors and community.

This will be immediately followed by the coding period from June 13 to September 4. After which, the contributors are expected to submit their final work, evaluate their mentors, and get evaluated by their mentors as well. Results will be announced on September 20.

For more information about the Google Summer of Code 2022 kindly refer to the official GSoC website.

We would like to express our gratitude to Google for organizing the yearly GSoC, and to The NetBSD Foundation mentors and administrators for their efforts and hardwork!

Let us welcome all the contributors to our growing NetBSD community!

We are happy to announce that The NetBSD Fundation is a mentoring organization at Google Summer of Code 2022!

Would you like to contribute to NetBSD or pkgsrc during the summer? Please give a look to NetBSD wiki Google Summer of Code page with possible ideas list and/or please join #NetBSD-code IRC channel on libera or get in touch with us via mailing lists to propose new projects!

Please note that unlike past years where Google Summer of Code was opened only to university students since this year if you are 18 or older you can be a GSoC contributor.

For more information about Google Summer of Code please give a look to the official GSoC website.

Looking forward to have a nice Google Summer of Code!

We are happy to announce that The NetBSD Fundation is a mentoring organization at Google Summer of Code 2022!

Would you like to contribute to NetBSD or pkgsrc during the summer? Please give a look to NetBSD wiki Google Summer of Code page with possible ideas list and/or please join #NetBSD-code IRC channel on libera or get in touch with us via mailing lists to propose new projects!

Please note that unlike past years where Google Summer of Code was opened only to university students since this year if you are 18 or older you can be a GSoC contributor.

For more information about Google Summer of Code please give a look to the official GSoC website.

Looking forward to have a nice Google Summer of Code!

The time has come to upgrade my SunBlade 2500s to something more power friendly and faster. I'd already removed one CPU and thus half the ram from two of these systems to reduce their power consumption, but it's still much higher than it could be.

After much searching, I've decided on Pine64's RockPro64 4GiB ram model (technically, only 3.875GiB ram.) Pine64 make SBCs, laptops, phones, and various other mostly ARM gadgets, and the RockPro64 has the fastest CPU they ship (Rockchip RK3399), and can use a small "NAS Case", that is sufficient to house 2 HDDs and, at a stretch, upto 6 SSDs (cooling would become quite an issue at this point.)

In my SATA setup, I have 3 SSDs with a JMicron 585 card in the PCIe slot, two SSDs in the NAS case SSD region, and the third is in the HDD region with an adapter. I have used two SATA power splitters to convert the NAS case's 2 SATA power ports into 4, with the 4th one also powering a Noctua case fan. The cabling is not great with this, with enough SATA power cabling for 6 devices to lay. Probably a bespoke power cable to connect to the RockPro64 would make this nicer and probably improve cooling slightly, but I'm just using off-the-shelf components for now.

In the last year or so I've been working on making NetBSD/arm64 big-endian more featureful. In particular, I've added support for:

• other-endian access disklabels, FFS file-systems in the NetBSD libsa
• the "look 64 sectors later" for RAIDFrame partitions in MI efiboot (the x86 specific efiboot has more extensive support for this that should be ported over)
• other-endian access to RAIDFrame labels in the kernel
• updated the U-Boot package and featureset to include AHCI/SATA support, workaround some bugs and fix the newer U-Boot SPI loader location, and figured out how to default loading from either SATA or NVMe

There are not too many special actions needed for this sort of setup compared to a normal NetBSD or Arm system. While I built my installations by hand, the standard NetBSD Arm images are suitable for this task. It's easiest to start from an SD card with the RockPro64 u-boot installed. There are two U-Boot images available, one for SD/eMMC, and one for SPI (there is an odd problem with the early SPI loader that requires a portion of the image to be different.) The pkgsrc package for sysutils/u-boot-rockpro64 version 2022.01 has these suggested methods for installing the U-Boot image (this package should be buildable on any supported pkgsrc platform).

To install U-Boot into the SD/eMMC card (can run on any system, the image must be written at 32KiB into the device):

# dd if=/usr/pkg/share/u-boot/rockpro64/rksd_loader.img seek=64 of=/dev/rld0c

To install U-Boot into the SPI flash (must be run on the host, and lives at the very start of the device:

# dd if=/usr/pkg/share/u-boot/rockpro64/rkspi_loader.img bs=64k of=/dev/spiflash0

When booting from NVMe or SATA, one must drop to the U-Boot prompt and adjust the "boot_targets" value to put scsi* (SATA) or nvme* ahead of the mmc* and usb* options.

The original value for me:

=> printenv boot_targets
boot_targets=mmc1 usb0 mmc0 nvme0 scsi0 pxe dhcp sf0

Which is then adjusted and saved with eg:

=> setenv boot_targets nvme0 scsi0 mmc1 usb0 mmc0 pxe dhcp sf0
=> saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK

(In this list, mmc1 is the SD slot, mmc0 is the eMMC card, pxe and dhcp are netbooting, and sf0 attempts to load further U-Boot scripts from SPI.)

There are some minor issues with the RockPro64. It has no ability to use ECC memory. It only comes with 1 PCIe 4x slot, and Rockchip errata limited this to PCIe 1.x (though no NetBSD users encounted any issues with PCIe 2.x enabled, and this can be forced back on via a DTS patch.) It is possible to use a PCIe bridge (I have never done this, though I would like to try in the future) to enable more devices for booting, or to enable both a network and storage device.

The time has come to upgrade my SunBlade 2500s to something more power friendly and faster. I'd already removed one CPU and thus half the ram from two of these systems to reduce their power consumption, but it's still much higher than it could be.

After much searching, I've decided on Pine64's RockPro64 4GiB ram model (technically, only 3.875GiB ram.) Pine64 make SBCs, laptops, phones, and various other mostly ARM gadgets, and the RockPro64 has the fastest CPU they ship (Rockchip RK3399), and can use a small "NAS Case", that is sufficient to house 2 HDDs and, at a stretch, upto 6 SSDs (cooling would become quite an issue at this point.)

In my SATA setup, I have 3 SSDs with a JMicron 585 card in the PCIe slot, two SSDs in the NAS case SSD region, and the third is in the HDD region with an adapter. I have used two SATA power splitters to convert the NAS case's 2 SATA power ports into 4, with the 4th one also powering a Noctua case fan. The cabling is not great with this, with enough SATA power cabling for 6 devices to lay. Probably a bespoke power cable to connect to the RockPro64 would make this nicer and probably improve cooling slightly, but I'm just using off-the-shelf components for now.

In the last year or so I've been working on making NetBSD/arm64 big-endian more featureful. In particular, I've added support for:

• other-endian access disklabels, FFS file-systems in the NetBSD libsa
• the "look 64 sectors later" for RAIDFrame partitions in MI efiboot (the x86 specific efiboot has more extensive support for this that should be ported over)
• other-endian access to RAIDFrame labels in the kernel
• updated the U-Boot package and featureset to include AHCI/SATA support, workaround some bugs and fix the newer U-Boot SPI loader location, and figured out how to default loading from either SATA or NVMe

There are not too many special actions needed for this sort of setup compared to a normal NetBSD or Arm system. While I built my installations by hand, the standard NetBSD Arm images are suitable for this task. It's easiest to start from an SD card with the RockPro64 u-boot installed. There are two U-Boot images available, one for SD/eMMC, and one for SPI (there is an odd problem with the early SPI loader that requires a portion of the image to be different.) The pkgsrc package for sysutils/u-boot-rockpro64 version 2022.01 has these suggested methods for installing the U-Boot image (this package should be buildable on any supported pkgsrc platform).

To install U-Boot into the SD/eMMC card (can run on any system, the image must be written at 32KiB into the device):

# dd if=/usr/pkg/share/u-boot/rockpro64/rksd_loader.img seek=64 of=/dev/rld0c

To install U-Boot into the SPI flash (must be run on the host, and lives at the very start of the device:

# dd if=/usr/pkg/share/u-boot/rockpro64/rkspi_loader.img bs=64k of=/dev/spiflash0

When booting from NVMe or SATA, one must drop to the U-Boot prompt and adjust the "boot_targets" value to put scsi* (SATA) or nvme* ahead of the mmc* and usb* options.

The original value for me:

=> printenv boot_targets
boot_targets=mmc1 usb0 mmc0 nvme0 scsi0 pxe dhcp sf0

Which is then adjusted and saved with eg:

=> setenv boot_targets nvme0 scsi0 mmc1 usb0 mmc0 pxe dhcp sf0
=> saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK

(In this list, mmc1 is the SD slot, mmc0 is the eMMC card, pxe and dhcp are netbooting, and sf0 attempts to load further U-Boot scripts from SPI.)

There are some minor issues with the RockPro64. It has no ability to use ECC memory. It only comes with 1 PCIe 4x slot, and Rockchip errata limited this to PCIe 1.x (though no NetBSD users encounted any issues with PCIe 2.x enabled, and this can be forced back on via a DTS patch.) It is possible to use a PCIe bridge (I have never done this, though I would like to try in the future) to enable more devices for booting, or to enable both a network and storage device.

This post was written by Piyush Sachdeva:

Abstract

The primary goal of the project was to extend posix_spawn(3) to include chdir(2) for the newly created child process. Two functions were supposed to be implemented, namely posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir(), to support both chdir(2) and fchdir(2) respectively. posix_spawn() is a POSIX standard method responsible for creating and executing new child processes.

Implementation

The original code can be found at my github tree.

The implementation plan was discussed and made with the guidance of both my mentors Martin Husemann and Joerg Sonnenberger. The plan was divided into three phases each corresponding to the specific part of The NetBSD code-base which is supposed to be touched:

User-Land

The following actions were performed in the user-land to set things up for the kernel-space.

• Add another member to the posix_spawn_file_actions_t struct i.e a union, which would hold the path to chdir to.
• Implement the two functions posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir(). These functions would:
  1. allocate memory for another posix_spawn_file_actions_t object in the posix_spawn_file_actions_t array.
  2. take the path/file descriptor from the user as an argument and make the relative field of the newly allocated file actions object, point to it.
• The final step was to add the prototypes for the two new functions to the `src/include/spawn.h' header file

Once the aforementioned changes were made, the only thing left to do was to make the kernel support these two new functions.

Kernel-Space

The following actions were performed inside the kernel space.

• The three functions in the `src/sys/kern_exec.c' file which correspond to the posix_spawn_file_actions were edited:
  • posix_spawn_fa_alloc() was adjusted to make sure that the path passed to posix_spawn_file_actions_addchdir() gets copied from the user-land to the kernel-space.
  • Similarly posix_spawn_fa_free() was adjusted to make sure that the memory allocated in case of FAE_CHDIR gets freed as well.
  • Finally, two new cases FAE_CHDIR & FAE_FCHDIR were added in the handle_posix_spawn_file_actions(). In each of the cases, a call to one of the two newly created functions (discussed in the next point) do_sys_chdir() and do_sys_fchdir() was made respectively.

  Note: At the time of code integration, a helper function was written by Christos Zoulas. This function aimed to reduce the amount of repeated code in both posix_spawn_fa__free() and posix_spawn_fa_alloc()

• Two new functions, similar to the already present sys_chdir() and sys_fchdir() in `src/sys/vfs_syscalls.c' were created. Namely do_sys_chdir() and do_sys_chdir were written with two specific thoughts in mind:
  • By default sys_chdir() and sys_fchdir() took syscallargs as a parameter. The purpose of the new functions was to replace this with const char * and an int type parameter respectively.
  • The do_sys_chdir() also replaced UIO_USERSPACE with UIO_SYSSPACE. This was done because the chdir path passed to this function already resided in the Kernel-space due to the change made in posix_spawn_fa_alloc().
• Finally, the prototypes for the newly written functions were added to the `src/sys/sys/vfs_syscalls.h' file and this file was also included in the 'sys/kern/kern_exec.c'.

Note: Similar to the above changes of user-land and kernel-space, a few tweaks were also made to `src/sys/compat/netbsd/netbsd32.h' and `netbsd32_execve.c'. This was required to help COMPAT_NETBSD32 deal with the new file actions member. However, these changes were made at the time of integration by Martin Husemann.

With most of addition of new features being done, all that remained was testing and documentation.

Testing & Documentation

• A total of ten new test cases have been added to the `src/tests/lib/libc/gen/posix_spawn/t_spawn.c' file.
• Three utility functions were also used to aid in testing. Out of the three, one new function was written and two existing functions (filesize() and empty_outfile()) from `t_fileactions.c' were used. To make sure that the 2 existing functions were shared between both the files i.e `t_spawn.c' and `t_fileactions.c' a new header and C file was created, namely `fa_spawn_utils.h' and `fa_spawn_utils.c'. Following this, the bodies of both the functions were moved from `t_fileactions.c' to `fa_spawn_utils.c' and their prototypes were added to the corresponding header file.
• The general approach that was taken to all test cases was to make posix_spawn() execute ``/bin/pwd'' and write the output to a file. Then read the file and do string comparison. The third function i.e. check_succes() was written for just this purpose.
• The ten test cases cover the following scenarios:
  • Absolute path test - for both chdir and fchdir.
  • Relative path test - for both chdir and fchdir.
  • Trying to open a file instead of directory - for both chdir and fchdir.
  • Invalid path/file descriptor (fd=-1) - for both chdir and fchdir.
  • Trying to open a directory without access permissions for chdir.
  • Opening a closed file descriptor for fchdir.
• The first 8 test cases had a lot of repetitive code. Therefore, at the time of integration, another function was created i.e spawn_chdir(). This function included a huge chunk of the common code and it did all the heavy lifting for those first 8 test cases.

Documentation:

In this matter, a complete man page is written which explains both posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir() in great detail. The content of the manual page is taken from the POSIX documentation provided to us by Robert Elz.

Issues

Since the project was well planned from the beginning, it resulted in few issues.

• The user-land was the most straight forward part of the project and I had no trouble sailing through it.
• Kernel space was where things got a bit complicated, as I had to add functionality to pre-existing functions.
• I was completely new to using atf(7) and groff(1). Therefore, it took me some time to understand the respective man pages and become comfortable with testing and documentation part.

Most of the issues faced were generally logistical. As it was my first time doing a kernel project, I was new to building from source, Virtual Machines and other things like SSH. But luckily, I had great help from my mentors and the entire NetBSD community.

Thanks

I would like to express my heartfelt gratitude to The NetBSD Foundation for giving me this opportunity and sponsoring the Project. This project would not have been possible without the constant support and encouragement of both my mentors Martin Husemann and Joerg Sonnenberger. My gratitude to Christos Zoulas who worked on the crucial part of integrating the code. A special mention to all of the other esteemed NetBSD developers, who have helped me navigate through the thick and thin of this project and have answered even my most trivial questions.

This post was written by Piyush Sachdeva:

Abstract

The primary goal of the project was to extend posix_spawn(3) to include chdir(2) for the newly created child process. Two functions were supposed to be implemented, namely posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir(), to support both chdir(2) and fchdir(2) respectively. posix_spawn() is a POSIX standard method responsible for creating and executing new child processes.

Implementation

The original code can be found at my github tree.

The implementation plan was discussed and made with the guidance of both my mentors Martin Husemann and Joerg Sonnenberger. The plan was divided into three phases each corresponding to the specific part of The NetBSD code-base which is supposed to be touched:

User-Land

The following actions were performed in the user-land to set things up for the kernel-space.

• Add another member to the posix_spawn_file_actions_t struct i.e a union, which would hold the path to chdir to.
• Implement the two functions posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir(). These functions would:
  1. allocate memory for another posix_spawn_file_actions_t object in the posix_spawn_file_actions_t array.
  2. take the path/file descriptor from the user as an argument and make the relative field of the newly allocated file actions object, point to it.
• The final step was to add the prototypes for the two new functions to the `src/include/spawn.h' header file

Once the aforementioned changes were made, the only thing left to do was to make the kernel support these two new functions.

Kernel-Space

The following actions were performed inside the kernel space.

• The three functions in the `src/sys/kern_exec.c' file which correspond to the posix_spawn_file_actions were edited:
  • posix_spawn_fa_alloc() was adjusted to make sure that the path passed to posix_spawn_file_actions_addchdir() gets copied from the user-land to the kernel-space.
  • Similarly posix_spawn_fa_free() was adjusted to make sure that the memory allocated in case of FAE_CHDIR gets freed as well.
  • Finally, two new cases FAE_CHDIR & FAE_FCHDIR were added in the handle_posix_spawn_file_actions(). In each of the cases, a call to one of the two newly created functions (discussed in the next point) do_sys_chdir() and do_sys_fchdir() was made respectively.

  Note: At the time of code integration, a helper function was written by Christos Zoulas. This function aimed to reduce the amount of repeated code in both posix_spawn_fa__free() and posix_spawn_fa_alloc()

• Two new functions, similar to the already present sys_chdir() and sys_fchdir() in `src/sys/vfs_syscalls.c' were created. Namely do_sys_chdir() and do_sys_chdir were written with two specific thoughts in mind:
  • By default sys_chdir() and sys_fchdir() took syscallargs as a parameter. The purpose of the new functions was to replace this with const char * and an int type parameter respectively.
  • The do_sys_chdir() also replaced UIO_USERSPACE with UIO_SYSSPACE. This was done because the chdir path passed to this function already resided in the Kernel-space due to the change made in posix_spawn_fa_alloc().
• Finally, the prototypes for the newly written functions were added to the `src/sys/sys/vfs_syscalls.h' file and this file was also included in the 'sys/kern/kern_exec.c'.

Note: Similar to the above changes of user-land and kernel-space, a few tweaks were also made to `src/sys/compat/netbsd/netbsd32.h' and `netbsd32_execve.c'. This was required to help COMPAT_NETBSD32 deal with the new file actions member. However, these changes were made at the time of integration by Martin Husemann.

With most of addition of new features being done, all that remained was testing and documentation.

Testing & Documentation

• A total of ten new test cases have been added to the `src/tests/lib/libc/gen/posix_spawn/t_spawn.c' file.
• Three utility functions were also used to aid in testing. Out of the three, one new function was written and two existing functions (filesize() and empty_outfile()) from `t_fileactions.c' were used. To make sure that the 2 existing functions were shared between both the files i.e `t_spawn.c' and `t_fileactions.c' a new header and C file was created, namely `fa_spawn_utils.h' and `fa_spawn_utils.c'. Following this, the bodies of both the functions were moved from `t_fileactions.c' to `fa_spawn_utils.c' and their prototypes were added to the corresponding header file.
• The general approach that was taken to all test cases was to make posix_spawn() execute ``/bin/pwd'' and write the output to a file. Then read the file and do string comparison. The third function i.e. check_succes() was written for just this purpose.
• The ten test cases cover the following scenarios:
  • Absolute path test - for both chdir and fchdir.
  • Relative path test - for both chdir and fchdir.
  • Trying to open a file instead of directory - for both chdir and fchdir.
  • Invalid path/file descriptor (fd=-1) - for both chdir and fchdir.
  • Trying to open a directory without access permissions for chdir.
  • Opening a closed file descriptor for fchdir.
• The first 8 test cases had a lot of repetitive code. Therefore, at the time of integration, another function was created i.e spawn_chdir(). This function included a huge chunk of the common code and it did all the heavy lifting for those first 8 test cases.

Documentation:

In this matter, a complete man page is written which explains both posix_spawn_file_actions_addchdir() and posix_spawn_file_actions_addfchdir() in great detail. The content of the manual page is taken from the POSIX documentation provided to us by Robert Elz.

Issues

Since the project was well planned from the beginning, it resulted in few issues.

• The user-land was the most straight forward part of the project and I had no trouble sailing through it.
• Kernel space was where things got a bit complicated, as I had to add functionality to pre-existing functions.
• I was completely new to using atf(7) and groff(1). Therefore, it took me some time to understand the respective man pages and become comfortable with testing and documentation part.

Most of the issues faced were generally logistical. As it was my first time doing a kernel project, I was new to building from source, Virtual Machines and other things like SSH. But luckily, I had great help from my mentors and the entire NetBSD community.

Thanks

I would like to express my heartfelt gratitude to The NetBSD Foundation for giving me this opportunity and sponsoring the Project. This project would not have been possible without the constant support and encouragement of both my mentors Martin Husemann and Joerg Sonnenberger. My gratitude to Christos Zoulas who worked on the crucial part of integrating the code. A special mention to all of the other esteemed NetBSD developers, who have helped me navigate through the thick and thin of this project and have answered even my most trivial questions.

After initial work on the wifi renewal branch went quite fast and smooth, things have slowed down a bit in the last few months.

Most of the slow down was due to me not being available for this type of work for unexpectedly long times - a problem that should be fixed now.

However, there were other obstacles and unexpected issues on the way:

• bpf taps are handled differently in the new stack and some slightly obscure site conditions of this had been overlooked in the initial conversion. To make everything work, changes to our bpf framework were needed (and have landed in -current some time ago now).
• Many wifi drivers seem to be in a, let's say, slightly fragile state. When testing the random collection of wifi hardware that I acquired during this project in -current, many drivers did not work at first try and often I was able to provoke kernel panics quickly. This is not a happy base to start converting drivers from.
• After the great success of usbnet(9) for USB ethernet drivers, core and I agreed to do the same for wifi - the result is called usbwifi(9) and makes conversion of usb drivers a lot easier than other wifi drivers. See the conversion instructions for more details. usbwifi(9) is both quite similar but also quite different to usbnet(9), mostly for two reasons: it interfaces to a totally different stack, and many usb wlan chipsets are more complex than ethernet chipsets (e.g. have support for multiple send queues with different priorities). Developing usbwifi did cost quit some time (initially unplanned), but is expected to amortize over the next few drivers and quickly end up as a net win.
• I have been hitting a bug in the urtwn(4) driver used for inial usbwifi(9) development and still not found it (as of today). It seems to hit randomly and not be caused by the usbwifi(9) conversion - a fact that I found out only recently. So for now I will put this driver aside (after spending *way* too much time on it) and instead work on other usb drivers, returning to the bug every now and then and see if I can spot it. Maybe I can borrow a USB analyzer and get more insight that way.

The current state of driver conversion and what drivers are still open are listed in the wifi driver conversion matrix.

Next steps ahead are:

• make another pass over documentation and improve things / fixup for recent changes (done before this blog post got published)
• sync the branch with HEAD and keep tracking it more closely
• convert run(4) to usbwifi
• revisit rtwn(4) and decide if/how it should be merged with urtwn(4)
• revisit iwm(4) and make it work fully
• convert all other drivers, starting with the ones I have hardware for

Currently it is not clear if this branch can be merged to HEAD before branching for netbsd-10. We will not delay the netbsd-10 branch for this.

After initial work on the wifi renewal branch went quite fast and smooth, things have slowed down a bit in the last few months.

Most of the slow down was due to me not being available for this type of work for unexpectedly long times - a problem that should be fixed now.

However, there were other obstacles and unexpected issues on the way:

• bpf taps are handled differently in the new stack and some slightly obscure site conditions of this had been overlooked in the initial conversion. To make everything work, changes to our bpf framework were needed (and have landed in -current some time ago now).
• Many wifi drivers seem to be in a, let's say, slightly fragile state. When testing the random collection of wifi hardware that I acquired during this project in -current, many drivers did not work at first try and often I was able to provoke kernel panics quickly. This is not a happy base to start converting drivers from.
• After the great success of usbnet(9) for USB ethernet drivers, core and I agreed to do the same for wifi - the result is called usbwifi(9) and makes conversion of usb drivers a lot easier than other wifi drivers. See the conversion instructions for more details. usbwifi(9) is both quite similar but also quite different to usbnet(9), mostly for two reasons: it interfaces to a totally different stack, and many usb wlan chipsets are more complex than ethernet chipsets (e.g. have support for multiple send queues with different priorities). Developing usbwifi did cost quit some time (initially unplanned), but is expected to amortize over the next few drivers and quickly end up as a net win.
• I have been hitting a bug in the urtwn(4) driver used for inial usbwifi(9) development and still not found it (as of today). It seems to hit randomly and not be caused by the usbwifi(9) conversion - a fact that I found out only recently. So for now I will put this driver aside (after spending *way* too much time on it) and instead work on other usb drivers, returning to the bug every now and then and see if I can spot it. Maybe I can borrow a USB analyzer and get more insight that way.

The current state of driver conversion and what drivers are still open are listed in the wifi driver conversion matrix.

Next steps ahead are:

• make another pass over documentation and improve things / fixup for recent changes (done before this blog post got published)
• sync the branch with HEAD and keep tracking it more closely
• convert run(4) to usbwifi
• revisit rtwn(4) and decide if/how it should be merged with urtwn(4)
• revisit iwm(4) and make it work fully
• convert all other drivers, starting with the ones I have hardware for

Currently it is not clear if this branch can be merged to HEAD before branching for netbsd-10. We will not delay the netbsd-10 branch for this.