Re: [PATCH rdma-next V2 6/6] RDMA/core: Unify style of IOCTL commands

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]