On Tue, Sep 06, 2016 at 03:19:59PM -0600, Jason Gunthorpe wrote: > On Tue, Sep 06, 2016 at 05:03:14PM -0400, ira.weiny wrote: > > > These defines are _not_ used anywhere in the kernel but rather define a > > device specific command _offset_ within the drm vendor ioctl range. > > That is not completely true, the defines are used when setting up the > kernel ioctl #. I have no idea why they did this, to me it is > polluting a uapi header with unneeded defines which is a big no-no. Well... That is the same for the HFI1 defines as the __NUM macro expanded to those defines... #define __NUM(cmd) (HFI1_CMD_##cmd + 0xe0) But really aren't we just nit picking now? > > Userspace should certainly *NEVER* use these constants, removing them > is the best way to achieve that. I assume the DRM user space uses them to help distinguish between #define DRM_AMDGPU_GEM_CREATE 0x00 And #define DRM_I810_INIT 0x00 I'm not at all familiar with the drm user space code but I could see some sort of "provider" architecture where the providers pass these constants and some "core" layer adds the vendor offset automatically??? > > > When we agreed that HFI1 would use an 0x80 offset I thought that was the > > idea.[*] That IB would have an upper range which was device specific and HFI1 > > would be the first users of that range. > > I'd rather not have non-unique ioctls if we can avoid it...... I'm still mulling over the plan for this. > > But even if we do, removing these indirection constants does nothing to > change that - other drivers can still alias 0x80. Yes but having walked through the drm headers it is nice in how explicit they are. > > That is doable, particularly if the struct is a different size, then > we still have unique ioctl numbers. With some care other vendors can > probably manage... Yes, I am sure we can manage. There are always different ways to do things. In the end if Doug accepts this series we will manage in PSM. However, I really don't think what was done was "wrong". Ira > > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
