netdev - Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Jul 2018 07:35:49 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Doug Ledford <dledford@...hat.com>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        Yishai Hadas <yishaih@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data

On Wed, Jul 25, 2018 at 08:35:17AM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 25, 2018 at 08:37:03AM +0300, Leon Romanovsky wrote:
>
> > > Also, I would like to keep the specs consistently formatted according
> > > to clang-format with 'BinPackParameters: true', so I reflowed them as
> > > well.
> >
> > I'm using default VIM clang-format.py without anything in .clang-format.
> > Do you have an extra definitions there, except BinPackParameters?
>
> These days Linux includes a top level .clang-format that does a
> pretty good job.
>
> I have to manually switch BinPackParameters on when working with these
> specs to get the right indenting.. A pain, but maybe there is a better
> way someday..

I don't think that it is feasible to ask from people to change some
defaults only for patches that touch those specs. Any change in this
area will change formatting back.

Jason, bottom line, I won't use BinPackParameters for my patches.

Thanks

>
> Jason

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)