←back to thread

520 points OlympicMarmoto | 1 comments | | HN request time: 0s | source
Show context
jnwatson ◴[] No.45067216[source]
I've written a lot of low level software, BSPs, and most of an OS, and the main reason to not write your own OS these days is silicon vendors. Back in the day, they would provide you a spec detailed enough that you could feasibly write your own drivers.

These days, you get a medium-level description and a Linux driver of questionable quality. Part of this is just laziness, but mostly this is a function of complexity. Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for.

replies(13): >>45067491 #>>45069282 #>>45069287 #>>45069349 #>>45069690 #>>45070345 #>>45071036 #>>45071086 #>>45072259 #>>45072391 #>>45073789 #>>45075476 #>>45081942 #
boredatoms ◴[] No.45069282[source]
Presumably if you’re meta you could pay the vendors enough to write drivers for any arbitrary OS
replies(5): >>45069321 #>>45069853 #>>45070444 #>>45071037 #>>45073107 #
eklitzke ◴[] No.45070444[source]
Writing drivers is easy, getting vendors to write *correct* drivers is difficult. At work right now we are working with a Chinese OEM with a custom Wifi board with a chipset with firmware and drivers supplied by the vendor. It's actually not a new wifi chipset, they've used it in other products for years without issues. In conditions that are difficult to reproduce sometimes the chipset gets "stuck" and basically stops responding or doing any wifi things. This appears to be a firmware problem because unloading and reloading the kernel module doesn't fix the issue. We've supplied loads of pcap dumps to the vendor, but they're kind of useless to the vendor because (a) pcap can only capture what the kernel sees, not what the wifi chipset sees, (b) it's infeasible for the wifi chipset to log all its internal state and whatnot, and (c) even if this was all possible trying to debug the driver just from looking at gigabytes of low level protocol dumps would be impossible.

Realistically for the OEM to debug the issue they're going to need a way to reliably repro which we don't have for them, so we're kind of stuck.

This type of problem generalizes to the development of drivers and firmware for many complex pieces of modern hardware.

replies(1): >>45072223 #
throwaway2037 ◴[] No.45072223{3}[source]

    > custom Wifi board
Why didn't you use something more mainstream? Cost?
replies(1): >>45072441 #
1. typpilol ◴[] No.45072441{4}[source]
Probably some weird design spec or size requirement