3 ms·

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 / architect

by uluyol 5y 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.

JonChesterfield 5y 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 5y 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 5y ago
  I think that has more to do with DXGKRNL coming from Microsoft than any policy that would be applied to other contributers.
  - detaro 5y ago
    Other Microsoft contributions got into the kernel just fine.
    - monocasa 5y 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.
duskwuff 5y 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 5y 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...

by uluyol 5y ago

JonChesterfield 5y 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 5y 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 5y ago
I think that has more to do with DXGKRNL coming from Microsoft than any policy that would be applied to other contributers.
- detaro 5y ago
  Other Microsoft contributions got into the kernel just fine.
  - monocasa 5y 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.

duskwuff 5y 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 5y 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...