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

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

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

On Tue, Aug 16, 2016 at 05:09:27PM +0000, Dalessandro, Dennis wrote:
> On Tue, 2016-08-16 at 19:50 +0300, Leon Romanovsky wrote:
> > On Tue, Aug 16, 2016 at 02:31:32PM +0000, Dalessandro, Dennis wrote:
> > > On Tue, 2016-08-16 at 16:45 +0300, Leon Romanovsky wrote:
> > > > From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > > > 
> > > > MAD and HFI1 have different naming convention, this patch
> > > > simplifies and unifies their defines and names.
> > > 
> > > I don't know that I agree that it simplifies things. It changes a
> > > lot
> > > of code for not much real value in my opinion. 
> > > 
> > > Was this something that was discussed in the verbs call? I have not
> > > been able to attend that the last few weeks.
> > 
> > It was discussed over mails, for example Jason's opinion [1],
> > Christopher Lameter's opinion [2], Christoph Hellwig's opinion [3].
> 
> I'm not opposed to trying to unify things, however this seems to be
> more than plop down the hfi1 stuff from here and put it over there. It
> is certainly not simplifying anything.

It is "dark side" of UAPI - inability to change legacy declarations.
This is why I didn't remove anything except _NUM() macro.

The simplification comes from definition of one place for
declaration of IOCTLs numbers and exporting it to users. It gives
visibility for user space authors too.

> 
> > > > As part of cleanup, the HFI1 _NUM() macro was removed and MAD
> > > > indexes were renamed. It has a potential to break application
> > > > which use these defines directly.
> > > 
> > > Why do you want to remove the _NUM() macro that Doug just put in?
> > 
> > It is not used after refactoring and IMHO this macro doesn't
> > belong to UAPI, since it wouldn't in use by any users, but I'll be
> > glad to
> > get an examples of its usage in real user space applications
> > (libfabric???), if any.
> > 
> 
> That's a fair point. I can see getting rid of it now.
> 
> -Denny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]