On Thu, Sep 01, 2016 at 10:46:24AM -0600, Jason Gunthorpe wrote: > On Thu, Sep 01, 2016 at 02:05:44PM +0000, Dalessandro, Dennis wrote: > > > > +/* allocate HFI and context */ > > > +#define HFI1_CMD_ASSIGN_CTXT (HFI1_CMD_BASE + 0x01) > > > > This is a minor issue, but the problem here is when we build PSM > > against this kernel it will no longer work for older kernels because > > the value of HFI1_CMD_ASSIGN_CTXT has changed where as it used to be 1. > > Right now PSM is backwards compatible, this breaks that compatibility. > > What? Someone renumberd an ioctl? When? Why? How? > > Was this ioctl ever in a mainline non-staging kernel? If not, too bad, > deal with it in your user space.. > > If yes, can we revert the renumbering? Why was that even done?? > > > So while no one uses the __NUM() macro directly it lets us not change > > the PSM command values. Can we put that part back and keep the command > > values unchanged? > > Please no, do not do crazy subtle things like this. If the ioctl has > two valid numbers then you need two entries in the ioctl file. I didn't renumbered ioctls, but renumbered one of the internals number which is not used in kernel, but for any reasons used in their user-space. ➜ linux-rdma git:(master) grep -r HFI1_CMD_ASSIGN_CTXT drivers/infiniband/hw/hfi1/* include/* include/uapi/rdma/hfi/hfi1_user.h:#define HFI1_CMD_ASSIGN_CTXT 1 /* allocate HFI and context */ So what should I do? respin or not? > > Jason
Attachment:
signature.asc
Description: PGP signature
