OK, I was hoping to keep the ABI unchanged during upstreaming, but I realize that may not be realistic. And I feel I'm getting valuable feedback, so I don't want to limit myself with ABI requirements that are not necessary. I still don't have commit access to git repos on freedesktop.org. But I'm now planning to upload my WIP to the ROCm repositories on Github as upstreaming branches for ROCk (kernel) and ROCt (Thunk). I should have that in place in the next day or two. If I need to tweak the ABI in the upstreaming process, all I need to change in user mode is the Thunk, and I can make it available on my GitHub branch for people to try, regardless of ROCm release schedules. All the rest of the user mode stack should work unchanged as long as the Thunk API doesn't need to be changed. With that in mind, I'll remove the gaps from the ioctl assignment and accept that KFD will diverge (for the better) from our internal branch more or less significantly in the upstreaming process. What's the plan for upstreaming on your side. Do you want to push things incrementally? Or do you prefer to wait until everything (or most of it) is reviewed and tested on an upstream-based branch? If it's the latter, we could reshuffle the ioctls later to better match the current release ABI before going upstream. Regards, Felix On 2017-08-14 11:18 AM, Felix Kuehling wrote: > On 2017-08-13 05:08 AM, Oded Gabbay wrote: >> As in the previous patch, there is a hole here in the IOCTLs >> numbering. I suggest that when you upstream new IOCTLs, you will put >> them in consecutive numbers per the upstream driver, and then take >> that change downstream because you can easily change it in your >> driver. > We can easily change it downstream, but it makes it harder for people to > test the new upstream kernel with already released ROCm user mode > drivers that are easy to install and without having to wait a few weeks > for the next release. > > If testability is not a priority, then I'd rather upstream the new > ioctls in the order in which we made them. The only reason I'm going > out-of-order is to make testing as easy as possible, as early as > possible, with the most recently released user mode stack. > > It's your call, though. > > Regards, > Felix > >> Oded > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
