3 ms·

> A lot of this stuff won’t meet the standards of the Linux kernel without lots of work. Can you elaborate on this? I never got the impression that 'the standa

> A lot of this stuff won’t meet the standards of the Linux kernel without lots of work. Can you elaborate on this? I never got the impression that 'the standards of the Linux kernel' were some incredibly high bar.

cmrdporcupine 3y ago
How does questionably formatted, badly documented, insufficiently tested, and full of Chinese comments sound? That's what I've come expect from this space. In general, it's the usual: China, great at hardware... software an afterthought
- MichaelZuo 3y ago
  Why exactly is it so difficult to polish it up, document it properly, and translate as necessary, that it can't be accomplished by a few smart engineers in a few months?
  - mafuyu 3y ago
    It's very much doable. You see the big vendors upstream proactively, and they have whole teams supporting upstreaming efforts. But chip bring-up and driver support can be messy affairs. It's not just a matter of a driver working or not- hardware bugs or weird undocumented behavior show up all the time. If customers aren't exercising some feature of the chip, bugs can and will go undetected in that module. The datasheet only gets you so far, especially for undocumented hardware quirks, and the vendor is in a much better place to understand what's happening and fix them. It's an active process of reporting bugs, investigating them, and getting fixes merged upstream into the vendor's BSP, at the very least. This requires active maintenance, which means engineers on the vendor side. That's where the support contracts kick in. Upstreaming to Linux on top of all that means that you actually need to support and validate the set of features your chip claims to support. That means more thorough test and validation, code that meets the standards of the kernel, and more engineers to actively maintain the code. Not to mention the language barrier for Chinese chip vendors. Of course, any upstreaming efforts are great and I think things are trending in a good direction. Just pointing out that there are reasons things are the way they are. Fabbing a chip that isn't completely buggy and people want to buy is already a small miracle- better software support can always wait until the chip becomes a hit.
    - MichaelZuo 3y ago
      If it's doable by a few smart engineers in a few months, assuming there are no show stopping quirks, then that should imply the trustworthy, reliable, manufacturers get their stuff upstreamed, by whomever, and the unreliable ones don't.
  - kop316 3y ago
    Here's one example of a wifi driver for the pinephone: https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64-linux/-/blob/mobian-6.6/debian/patches/wireless/0084-8723cs-Add-a-new-driver-v5.12.2-7-g2de5ec386.2020101.patch?ref_type=heads https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64... The diff is 13.4 MiB and is over 200,000 lines long. It includes it's own AES and SHA-256 engine. Trying to polish this up would be close to years, and a good kernel dev is not cheap.
    - MichaelZuo 3y ago
      Thanks, that does look substantial.

cmrdporcupine 3y ago

How does questionably formatted, badly documented, insufficiently tested, and full of Chinese comments sound? That's what I've come expect from this space. In general, it's the usual: China, great at hardware... software an afterthought

MichaelZuo 3y ago
Why exactly is it so difficult to polish it up, document it properly, and translate as necessary, that it can't be accomplished by a few smart engineers in a few months?
- mafuyu 3y ago
  It's very much doable. You see the big vendors upstream proactively, and they have whole teams supporting upstreaming efforts. But chip bring-up and driver support can be messy affairs. It's not just a matter of a driver working or not- hardware bugs or weird undocumented behavior show up all the time. If customers aren't exercising some feature of the chip, bugs can and will go undetected in that module. The datasheet only gets you so far, especially for undocumented hardware quirks, and the vendor is in a much better place to understand what's happening and fix them. It's an active process of reporting bugs, investigating them, and getting fixes merged upstream into the vendor's BSP, at the very least. This requires active maintenance, which means engineers on the vendor side. That's where the support contracts kick in. Upstreaming to Linux on top of all that means that you actually need to support and validate the set of features your chip claims to support. That means more thorough test and validation, code that meets the standards of the kernel, and more engineers to actively maintain the code. Not to mention the language barrier for Chinese chip vendors. Of course, any upstreaming efforts are great and I think things are trending in a good direction. Just pointing out that there are reasons things are the way they are. Fabbing a chip that isn't completely buggy and people want to buy is already a small miracle- better software support can always wait until the chip becomes a hit.
  - MichaelZuo 3y ago
    If it's doable by a few smart engineers in a few months, assuming there are no show stopping quirks, then that should imply the trustworthy, reliable, manufacturers get their stuff upstreamed, by whomever, and the unreliable ones don't.
- kop316 3y ago
  Here's one example of a wifi driver for the pinephone: https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64-linux/-/blob/mobian-6.6/debian/patches/wireless/0084-8723cs-Add-a-new-driver-v5.12.2-7-g2de5ec386.2020101.patch?ref_type=heads https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64... The diff is 13.4 MiB and is over 200,000 lines long. It includes it's own AES and SHA-256 engine. Trying to polish this up would be close to years, and a good kernel dev is not cheap.
  - MichaelZuo 3y ago
    Thanks, that does look substantial.