On Wed, Dec 23, 2015 at 12:00:41PM +0200, Or Gerlitz wrote: > On 12/21/2015 9:53 AM, Leon Romanovsky wrote: > >On Mon, Dec 21, 2015 at 9:40 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: > >>On Mon, Dec 21, 2015 at 9:27 AM, Leon Romanovsky <l...@leon.nu> wrote: > >>>On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: > >>>>On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <l...@leon.nu> wrote: > >>>>>On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.we...@intel.com> wrote: > >>>>>>On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote: > >>>>>>>From: Leon Romanovsky <leo...@mellanox.com> > >>>>>>>Modify enum ib_device_cap_flags such that other patches which add new > >>>>>>>enum values pass strict checkpatch.pl checks. > >>>>>>>- IB_DEVICE_RESERVED = (1<<16), /* old SEND_W_INV */ > >>>>>>>- IB_DEVICE_MEM_WINDOW = (1<<17), > >>>>>>>+ IB_DEVICE_RESIZE_MAX_WR = (1 << 0), > >>>>>2. Change the whole file => the work with "git blame" will be less > >>>>>straightforward. > >>>>Agree. > >>>> > >>>>Leon, I don't think we need to take checkpatch-ing of things to that > >>>>level. > >>>> > >>>>Indeed, we should make sure that whole new enums and such are done right > >>>>-- > >>>>but avoid touching core structs/enums in a manner that disallows > >>>>simple git blaming of things, which is very useful for new comers and > >>>>old suffers. > >>>There are no doubts that standalone fixing checkpatch errors is more > >>>suitable to staging subsystem. > >>Agree > >> > >>>In our case, it is part of coming changes in that structure. such > >>>change serves specific goal to minimize the possibility of error > >>>by seeing clean output from static analyser tool. > >>Disagree. > >> > >>What future bugs are you envisioning by let this 10y old header file > >>keep having some checkpatch issues on few of the major enums?! > >If I knew the future, I would be able to answer. > > Use your common-sense and experience and maybe even some credit that you can > give to the 10x larger and super active networking community, you should be > able to provide some answer if you believe this is the right way to go. My common-sense and experience suggest me that the proposed patch doesn't worth investing so much time. I'll drop it in the next version of this patchset.
> > >I think that you expressed your opinion very clearly, let's wait for Doug's > >response on such changes. > > > > I expressed my opinion and I ask you Qs. Christoph also made more comments, > if you think this is the way to go, respond. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
