Message ID | Zo_3ustogPDVKZwu@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [PULL] drm-xe-next-fixes v2 | expand |
On 2024-07-11 08:18:18, Rodrigo Vivi wrote: > Hi Dave and Sima, > > This is a v2 of https://lore.kernel.org/intel-xe/Zo2sO4t32dxqy6Q7@intel.com/ > > v2 - Removed Thomas' write-back caching mode patch since Lucas will propagete > that through drm-xe-fixes towards 6.10. So we remove the amount of patch > duplication. > > Again, it is important to highlight the uapi rename present in this > pull-request. > Mesa is aligned and waiting to merge their side: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30027 > > Since this uapi was recently merged, after we get both sides propagate > there won't be any kernel or mesa releases with the old bad naming. > So we should be good. This looks to be a simple rename, and it appears that the binary interface is functionally the same. So, even if there was a Mesa release using the old header, it should function fine with the interface to the kernel regardless of which header the kernel used. If the binary interface had changed, I'm not sure an argument of "no kernel or Mesa releases have happened" would be a good way to justify such a change. Luckily that is not the case here anyway. -Jordan
On Thu, Jul 11, 2024 at 02:29:04PM -0700, Jordan Justen wrote: > On 2024-07-11 08:18:18, Rodrigo Vivi wrote: > > Hi Dave and Sima, > > > > This is a v2 of https://lore.kernel.org/intel-xe/Zo2sO4t32dxqy6Q7@intel.com/ > > > > v2 - Removed Thomas' write-back caching mode patch since Lucas will propagete > > that through drm-xe-fixes towards 6.10. So we remove the amount of patch > > duplication. > > > > Again, it is important to highlight the uapi rename present in this > > pull-request. > > Mesa is aligned and waiting to merge their side: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30027 > > > > Since this uapi was recently merged, after we get both sides propagate > > there won't be any kernel or mesa releases with the old bad naming. > > So we should be good. > > This looks to be a simple rename, and it appears that the binary > interface is functionally the same. So, even if there was a Mesa > release using the old header, it should function fine with the > interface to the kernel regardless of which header the kernel used. > > If the binary interface had changed, I'm not sure an argument of "no > kernel or Mesa releases have happened" would be a good way to justify > such a change. Luckily that is not the case here anyway. Agreed. If it was that drastic we should never do and this argument shouldn't apply. But it is not so transparent as a full rename because there's one sysfs file name that also changed with the rest of the renaming. :/ > > -Jordan