Drivers are moving to user space too, but it's another case of something that will phase-in over two versions of the OS.
>DriverKit is a new SDK with all new frameworks based on IOKit but updated and modernized, designed for building Driver Extensions in user space outside the kernel.
You can build and test certain types of drivers in Catalina, but they won't be required until the next version of the OS ships.
>In Catalina, you can control USB, Serial, Network Interface, and Human Interface devices.
They will announce support for more kinds of user space drivers over time.
If there is not an available user space option for a particular use case, the existing kernel space option will continue to work.
I'm curious which ones -- CDC drivers are supported automatically and since Mavericks there is built-in support for FTDI and CH340G written by Apple. I think there is still a PL2303 driver but I've not used something with one of those for a couple of years.
I definitely do not miss the kernel panics from unplugging an older FTDI based Arduino while it was sending serial data!
I've had some problems with one device I've got with the Apple-provided driver and an FTDI adapter. Looks like the Mac doesn't respect hardware flow control, or the flow control is configured in some slightly different way, and it continues to send data even when the other end says it isn't ready.
Works fine with the FTDI driver and pre-Mavericks Apple drivers.
(I'd far rather use the Apple driver, which is much better at reliably detecting the device without needing to reinsert it, so this is a bit tiresome...)
FWIW, I’m having serious issues with my FTDI board on Catalina —- even after installing the VCP driver. I’ve had to downgrade to Mojave for the time being
Apple’s FTDI driver doesn’t seem to support baud rate aliasing, so nonstandard rates are not possible. FTDI chips are very capable but interfacing with them is surprisingly difficult on macOS.
I've typically gone a different route and used an ATMega32U2 (or U4) with Dean Camera's LUFA code to create a CDC to custom hardware bridge. Then the baud rate is irrelevant (or you can use it to set modes). I did this because OpenOCD was taking many, many minutes to program a tiny XC95144 CPLD using an FTDI JTAG cable. Yeah, sorry, trying to do it the "cheap way". When I got it working, the ATMega32U2 "serial" solution could do it in 2.3 seconds. Admittedly this was a few years ago, so things have likely improved.
One funny thing I did find doing this; I have not checked recent macOS releases - I should, was that if "Camera" was in the USB Device Descriptor the device would get claimed as a "serially attached camera" and the "serial" port would not show up - doh.