On Tue, Dec 27, 2022 at 9:26 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Dec 26, 2022 at 11:32:26PM +0200, Oded Gabbay wrote: > > Move the habanalabs.h uapi file from include/uapi/misc to > > include/uapi/drm, and rename it to habanalabs_accel.h. > > > > This is required before moving the actual driver to the accel > > subsystem. > > What requires this? Isn't this going to break userspace code? Yes, most definitely it will break userspace code. Moreover, the patches I'll send in 1-2 weeks to change the device char files will also break it. Having said that, I'm not worried because I don't believe anyone is working with the upstream version because there is no NIC support (yet). If this is unacceptable, I can offer a couple of alternatives and we can discuss what's best: 1. Do what AMD did a couple of years ago with radeon and amdgpu. We keep the habanalabs original driver in misc to support Goya, Gaudi1 and Gaudi2 (only with the current features). Create a new habanalabs driver in accel that will support only Gaudi2 and beyond. Our NIC driver (which I will start upstreaming in a few months) anyway will only support Gaudi2, so it will only work with the new driver. Make the drivers mutually exclusive in Kconfig. Gaudi2 as-is will be supported in the current driver, but if users want to use new features (and NIC), they will need to move to the new driver. 2. Move the driver to the new accel, but keep a copy of the uapi file in misc (to prevent breaking include paths). In addition, expose both new accel device char file (through drm code) and current habanalabs char file. Users can "acquire" the device through either /dev/accel/accel0 or /dev/hl0. Add new uapi content only to the uapi file in include/uapi/drm. This is what I'm going to do in our internal tree that we release as an out-of-tree driver to customers. 3. Keep the driver in misc. Clone it to accel only for next-gen ASIC, whenever that may be. WDYT ? I'm sure there are additional variations of the three options above, or a different option entirely. Thanks, Oded > > thanks, > > greg k-h
