On Tue, Mar 31, 2026 at 07:35:46AM -0600, Keith Busch wrote: > On Tue, Mar 31, 2026 at 04:29:42PM +0300, Leon Romanovsky wrote: > > On Tue, Mar 31, 2026 at 07:00:07AM -0600, Keith Busch wrote: > > > On Tue, Mar 31, 2026 at 11:37:58AM +0300, Leon Romanovsky wrote: > > > > On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote: > > > > > > > > > > You're suggesting that Ziping append the new fields to the end of this > > > > > struct? I don't think we can modify the layout of a uapi. > > > > > > > > He needs to add before flex array. This struct is submitted by the user > > > > and kernel can easily calculate the position of that array. > > > > > > No, you can't just do that. Existing applications would break when they > > > compile against the updated kernel header. They don't know about this > > > new "tph" supplied flag, but they'll all accidently use the new > > > dma_ranges offset. > > > > So we need to always pass TPH flag and treat 0 as do-nothing-field. > > I don't think you're understanding the implications. If Zhiping appends > new fields in front of the flex array dma_ranges, then existing > applications will implicitly use the new offset if they are recompiled > against the new kernel header. But if the binary was compiled against > the older kernel header, then that application would use the previous > offset. Both applications have the TPH flag cleared to 0. How is the > kernel supposed to know which offset the application used?
I understand, my proposal is always set TPH flag when new struct is used. Everything will be much easier if we can add fields after flex array. Thanks
