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@xxxxxxxxxxxx> > > > > > > > > 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:
signature.asc
Description: PGP signature
