5 ms·

The Google way: Force the rest of the world adjust to your new "cool thing", and then kill it because it wasn't that great.

monocasa 4y ago
Google isn't really forcing anyone to do anything in this case. Another RISC backend that was made clear would be ripped out of upstream the instant the Google maintainers stopped responding isn't really an imposition.
- uluyol 4y ago
  Would something like this be accepted in open source projects that are not significantly driven by Google? E.g. would Linux accept code for drivers / architectures that are not available to the public? I'm genuinely curious.
  - duskwuff 4y ago
    > E.g. would Linux accept code for drivers / architectures that are not available to the public? Drivers is an unequivocal "yes". Here's an example -- from Google, in fact: https://github.com/torvalds/linux/commit/e561bc45920aade3f8a5aad9058a00e750af1345 https://github.com/torvalds/linux/commit/e561bc45920aade3f8a... Architectures is less likely. But the pendulum has swung away from "making your own architecture" anyways.
    - b-rian 4y ago
      But hey, even with that example, the same mechanism got adapted to Chromebooks+Coreboot and now uses that same driver here: https://github.com/torvalds/linux/commit/d384d6f43d1ec3f1225ab0275fd592c5980bd830 https://github.com/torvalds/linux/commit/d384d6f43d1ec3f1225...
  - JonChesterfield 4y ago
    xcore (mentioned in that thread) is pretty obscure and still in trunk last I looked. Extra backends don't carry that much of a maintenance cost, mostly patching them up on api changes. Weirder targets hit bugs that the common ones don't so there's a benefit from having them in tree too. I'm not sure that generalises beyond modular compilers though.
  - rstat1 4y ago
    Given how ridiculously strict the Linux folks are being with the DXGKRNL stuff that MS is working on (which is public as part of WSLg), I would say definitely not.
    - monocasa 4y ago
      I think that has more to do with DXGKRNL coming from Microsoft than any policy that would be applied to other contributers.
      - detaro 4y ago
        Other Microsoft contributions got into the kernel just fine.
        monocasa 4y ago
        And other thin veneers over closed source paravirtualized VM graphics acceleration pipes get in as well, even from companies that flagrantly violate Linux's license. I think that it's a difference of subtree maintainer as to why some Microsoft code gets in and some is fought tooth and nail; you can't treat Linux developers as a monolith, and the graphics side is significantly more Microsoft adverse.
- hoten 4y ago
  The relevant discussion: https://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html https://lists.llvm.org/pipermail/llvm-dev/2016-February/0951... Seems the maintainers were more than happy to accept it, and even had policies in place for such contributions. One maintainer even mentioned it's a good policy because it brings more developers into using LLVM's ToT, which is overall good for project health.

monocasa 4y ago

Google isn't really forcing anyone to do anything in this case. Another RISC backend that was made clear would be ripped out of upstream the instant the Google maintainers stopped responding isn't really an imposition.

uluyol 4y ago
Would something like this be accepted in open source projects that are not significantly driven by Google? E.g. would Linux accept code for drivers / architectures that are not available to the public? I'm genuinely curious.
- duskwuff 4y ago
  > E.g. would Linux accept code for drivers / architectures that are not available to the public? Drivers is an unequivocal "yes". Here's an example -- from Google, in fact: https://github.com/torvalds/linux/commit/e561bc45920aade3f8a5aad9058a00e750af1345 https://github.com/torvalds/linux/commit/e561bc45920aade3f8a... Architectures is less likely. But the pendulum has swung away from "making your own architecture" anyways.
  - b-rian 4y ago
    But hey, even with that example, the same mechanism got adapted to Chromebooks+Coreboot and now uses that same driver here: https://github.com/torvalds/linux/commit/d384d6f43d1ec3f1225ab0275fd592c5980bd830 https://github.com/torvalds/linux/commit/d384d6f43d1ec3f1225...
- JonChesterfield 4y ago
  xcore (mentioned in that thread) is pretty obscure and still in trunk last I looked. Extra backends don't carry that much of a maintenance cost, mostly patching them up on api changes. Weirder targets hit bugs that the common ones don't so there's a benefit from having them in tree too. I'm not sure that generalises beyond modular compilers though.
- rstat1 4y ago
  Given how ridiculously strict the Linux folks are being with the DXGKRNL stuff that MS is working on (which is public as part of WSLg), I would say definitely not.
  - monocasa 4y ago
    I think that has more to do with DXGKRNL coming from Microsoft than any policy that would be applied to other contributers.
    - detaro 4y ago
      Other Microsoft contributions got into the kernel just fine.
      - monocasa 4y ago
        And other thin veneers over closed source paravirtualized VM graphics acceleration pipes get in as well, even from companies that flagrantly violate Linux's license. I think that it's a difference of subtree maintainer as to why some Microsoft code gets in and some is fought tooth and nail; you can't treat Linux developers as a monolith, and the graphics side is significantly more Microsoft adverse.
hoten 4y ago
The relevant discussion: https://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html https://lists.llvm.org/pipermail/llvm-dev/2016-February/0951... Seems the maintainers were more than happy to accept it, and even had policies in place for such contributions. One maintainer even mentioned it's a good policy because it brings more developers into using LLVM's ToT, which is overall good for project health.