Thanks for the input. I do _not_ intend to fork IOCTLs for new H/W generations, if possible. i.e, our driver now supports 2 h/w generations with the exact same set of IOCTLs and I don't see how that would change in the future.. What I'm more worried about is supporting different sets of UMD, which will require different IOCTLs for the same operation, e.g. CreateQueue for HSA runtime and OpenCL runtime. However, due to a very limited amount of UMDs, the "regular" way of adding IOCTLs may be sufficient. Bottom line, need to think more about it :) Oded On 09/10/14 18:55, Daniel Vetter wrote: > On Thu, Oct 9, 2014 at 12:15 PM, Oded Gabbay <oded.gabbay@xxxxxxx> wrote: >> Well, I don't expect to reach 100 ioctls anytime soon, but I can tell >> you that for the features we have in the pipeline, I can see the IOCTL >> number go up to 20-30, just for the current H/W generation. > > So our Android folks seem to routinely run out of ioctl numbers in > their product/downstream branches. But ime after some decent review of > the new interfaces and not just blindly creating interfaces because > that's easier we have rather slow ioctl number consumption in i915. So > presuming you do decent review and dont fork your driver for every > generation (which seems to be how every blob gfx driver team works) I > don't think you have a problem. Of course that's a massive change in > approach and in my experience with intel-internal discussion will > require a lot of training. > -Daniel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
