8 ms·

My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are

My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are against it.

tlow 10y ago
I believe this link is the "concrete argument" against a unified abstraction layer in this particular instance.
justincormack 10y ago
The open source developers don't care about invisible code reuse in a closed source driver. HALs across open source codebases do exist too (eg for ZFS) but Linux in particular does not like them.
- cpeterso 10y ago
  AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. AMD would get to reduce driver code duplication and Linux kernel developers don't need to merge the AMD's ugly Linux/Windows HAL.
  - wolfgke 10y ago
    > AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. This might theoretically make sense if the Linux subsystem was very stable over many years. Practice shows that the Windows interfaces are what are a lot more stable over the years and changes in them are communicated for a long time beforehand so that hardware vendors can begin changing their drivers long beforehand.
    - Kadin 10y ago
      Regardless of one's thoughts on AMD, I think this is broadly true. Microsoft may do a lot of things poorly, but one thing they are good at (arguably, the only thing they're good at, hell maybe the key to their success, really) is maintaining compatibility and not breaking stuff.
      - mixedCase 10y ago
        This is explained here: https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... Linux maintains compatibility by fixing the driver themselves when they break it. Microsoft cannot (actually, can, and does) break their interfaces since they don't control the drivers. This allows Linux to keep improving without breaking things in production; while Microsoft has to either maintain huge backward compatibility abstractions for changes, go YOLO and break stuff (often unknowingly) or abstain from improving their OS.
toast0 10y ago
(without looking at details) The problem is that Windows and Linux expose hardware and drivers in different ways. You can shim things up to make the code work, but you end up with a driver that doesn't look like a Linux driver and doesn't work like a Linux driver and can't easily be maintained by people working in the Linux graphics drivers is going to be a problem. If the driver doesn't really belong in the Linux kernel source for those reasons, it's better to keep it outside the kernel tree.
0xcde4c3db 10y ago
The problem isn't that sharing code across platforms is bad, it's that not sharing code within Linux is bad. Airlie is basically saying that if the kernel API and subsystems are somehow inadequate, AMD should improve them directly instead of covering them up with a bunch more code.
- wolfgke 10y ago
  > Airlie is basically saying that if the kernel API and subsystems are somehow inadequate, AMD should improve them directly instead of covering them up with a bunch more code. And you really believe that the maintainers will be accepting a giant patch that changes the API and subsystem completely (though into something better) that has the risk of causing lots of regressions to existing drivers? And you believe that AMD is supposed to fix all the regressions that are caused in drivers by other vendors that this change causes?
  - brongondwana 10y ago
    Of course not, the maintainers will accept a well thought out series of patches that each make one small logical change towards the better interface. And yes - who else is supposed to fix all the regressions caused by changes that AMD wants? Volunteers who would rather work on something else? If you want a change, you get to support the regressions - and if AMD's work gets merged, then anyone ELSE who wants to make a change in that page needs to support AMD's regressions. Hence wanting to make sure that the changes from AMD are manageable and flexible enough to allow further changes.
    - wolfgke 10y ago
      > If you want a change, you get to support the regressions And what about a change to a stable internal kernel API, which the kernel developers refuse?
      - pas 10y ago
        No, they just want a stable future, around which they can plan the API, but so far no one has delivered on that tiny requirement.
din-9 10y ago
It is a good thing for the driver writer as they have less difference between their targets. It is a bad thing for the targets as they implement both the driver functionality and the abstractions required to make the same code work cross platform. The response linked describes the cost of those abstractions to the target (Linux kernel in this case).
AnthonyMouse 10y ago
> My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are against it. A driver is inherently platform-specific. It's glue that ties the hardware to the operating system. The only "correct" way to have one driver work on multiple operating systems is for the operating systems to all use the same driver model. The ugly way is to create your own hardware abstraction layer and then write a translation layer between that and each operating system, because that's complicated and hideous. But it's especially silly because Linux accepts suitable contributed code, so you could instead use the native Linux model as your "intermediary layer" and fix Linux if it isn't suitable in some way. And then translate that to what the closed operating system you can't modify uses. The result is that the Linux people are happier and you have one less translation layer to maintain.
- nindalf 10y ago
  I agree with you almost entirely, except the part about fixing Linux. If the abstraction that Linux provides isn't suitable for some reason, it probably isn't straightforward to change it because of compatibility with existing code.
  - caf 10y ago
    That's not so much a concern within the kernel boundary, which is the case that applies here. If you have a compelling reason to redesign an internal API, you "just" have to fix up all the code across the tree that consumes it. Changes are regularly made to the internal VFS interfaces, for example.
    - wtallis 10y ago
      It's also often the case that kernel-driver interfaces are extended without breaking compatibility. In those cases, you want to ensure that the extensions are suitable for more than one driver to consume.
  - posterboy 10y ago
    Or future changes in the linux target need to be translated to all other target wrappers.
Qwertious 10y ago
AIUI, the problem is code re-use between drivers of different vendors but the same kernel/OS, VS code re-use between drivers of the same vendor but different kernels/OSes. At the end of the day, both sides are arguing for code re-use, of sorts.
tremon 10y ago
It is a good thing. For the developers of that piece of code (AMD in this case). However, it is introducing a second API for a very specific subset of hardware into a kernel that is being developed by not just AMD people. Dave Airlie is rightly saying that the second API and hence two different code structures makes the whole DRI infrastructure harder to maintain for everyone else. And Dave's responsibility is to everyone else, not to AMD.

My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are against it.

tlow 10y ago

I believe this link is the "concrete argument" against a unified abstraction layer in this particular instance.

justincormack 10y ago

The open source developers don't care about invisible code reuse in a closed source driver. HALs across open source codebases do exist too (eg for ZFS) but Linux in particular does not like them.

cpeterso 10y ago
AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. AMD would get to reduce driver code duplication and Linux kernel developers don't need to merge the AMD's ugly Linux/Windows HAL.
- wolfgke 10y ago
  > AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. This might theoretically make sense if the Linux subsystem was very stable over many years. Practice shows that the Windows interfaces are what are a lot more stable over the years and changes in them are communicated for a long time beforehand so that hardware vendors can begin changing their drivers long beforehand.
  - Kadin 10y ago
    Regardless of one's thoughts on AMD, I think this is broadly true. Microsoft may do a lot of things poorly, but one thing they are good at (arguably, the only thing they're good at, hell maybe the key to their success, really) is maintaining compatibility and not breaking stuff.
    - mixedCase 10y ago
      This is explained here: https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... Linux maintains compatibility by fixing the driver themselves when they break it. Microsoft cannot (actually, can, and does) break their interfaces since they don't control the drivers. This allows Linux to keep improving without breaking things in production; while Microsoft has to either maintain huge backward compatibility abstractions for changes, go YOLO and break stuff (often unknowingly) or abstain from improving their OS.

toast0 10y ago

(without looking at details) The problem is that Windows and Linux expose hardware and drivers in different ways. You can shim things up to make the code work, but you end up with a driver that doesn't look like a Linux driver and doesn't work like a Linux driver and can't easily be maintained by people working in the Linux graphics drivers is going to be a problem. If the driver doesn't really belong in the Linux kernel source for those reasons, it's better to keep it outside the kernel tree.

0xcde4c3db 10y ago

The problem isn't that sharing code across platforms is bad, it's that not sharing code within Linux is bad. Airlie is basically saying that if the kernel API and subsystems are somehow inadequate, AMD should improve them directly instead of covering them up with a bunch more code.

wolfgke 10y ago
> Airlie is basically saying that if the kernel API and subsystems are somehow inadequate, AMD should improve them directly instead of covering them up with a bunch more code. And you really believe that the maintainers will be accepting a giant patch that changes the API and subsystem completely (though into something better) that has the risk of causing lots of regressions to existing drivers? And you believe that AMD is supposed to fix all the regressions that are caused in drivers by other vendors that this change causes?
- brongondwana 10y ago
  Of course not, the maintainers will accept a well thought out series of patches that each make one small logical change towards the better interface. And yes - who else is supposed to fix all the regressions caused by changes that AMD wants? Volunteers who would rather work on something else? If you want a change, you get to support the regressions - and if AMD's work gets merged, then anyone ELSE who wants to make a change in that page needs to support AMD's regressions. Hence wanting to make sure that the changes from AMD are manageable and flexible enough to allow further changes.
  - wolfgke 10y ago
    > If you want a change, you get to support the regressions And what about a change to a stable internal kernel API, which the kernel developers refuse?
    - pas 10y ago
      No, they just want a stable future, around which they can plan the API, but so far no one has delivered on that tiny requirement.

din-9 10y ago

It is a good thing for the driver writer as they have less difference between their targets. It is a bad thing for the targets as they implement both the driver functionality and the abstractions required to make the same code work cross platform. The response linked describes the cost of those abstractions to the target (Linux kernel in this case).

AnthonyMouse 10y ago

> My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are against it. A driver is inherently platform-specific. It's glue that ties the hardware to the operating system. The only "correct" way to have one driver work on multiple operating systems is for the operating systems to all use the same driver model. The ugly way is to create your own hardware abstraction layer and then write a translation layer between that and each operating system, because that's complicated and hideous. But it's especially silly because Linux accepts suitable contributed code, so you could instead use the native Linux model as your "intermediary layer" and fix Linux if it isn't suitable in some way. And then translate that to what the closed operating system you can't modify uses. The result is that the Linux people are happier and you have one less translation layer to maintain.

nindalf 10y ago
I agree with you almost entirely, except the part about fixing Linux. If the abstraction that Linux provides isn't suitable for some reason, it probably isn't straightforward to change it because of compatibility with existing code.
- caf 10y ago
  That's not so much a concern within the kernel boundary, which is the case that applies here. If you have a compelling reason to redesign an internal API, you "just" have to fix up all the code across the tree that consumes it. Changes are regularly made to the internal VFS interfaces, for example.
  - wtallis 10y ago
    It's also often the case that kernel-driver interfaces are extended without breaking compatibility. In those cases, you want to ensure that the extensions are suitable for more than one driver to consume.
- posterboy 10y ago
  Or future changes in the linux target need to be translated to all other target wrappers.

Qwertious 10y ago

AIUI, the problem is code re-use between drivers of different vendors but the same kernel/OS, VS code re-use between drivers of the same vendor but different kernels/OSes. At the end of the day, both sides are arguing for code re-use, of sorts.

tremon 10y ago

It is a good thing. For the developers of that piece of code (AMD in this case). However, it is introducing a second API for a very specific subset of hardware into a kernel that is being developed by not just AMD people. Dave Airlie is rightly saying that the second API and hence two different code structures makes the whole DRI infrastructure harder to maintain for everyone else. And Dave's responsibility is to everyone else, not to AMD.