On Tue, Sep 17, 2019 at 9:16 AM Jason Gunthorpe wrote:
>
> On Fri, Sep 13, 2019 at 02:48:50PM +0300, Dan Carpenter wrote:
>
> > It used to be that infiniband used "sizeof foo" instead of sizeof(foo)
> > but now there is a new maintainer.
>
> These days I run everything through checkpatch and gener
On Fri, Sep 13, 2019 at 02:48:50PM +0300, Dan Carpenter wrote:
> It used to be that infiniband used "sizeof foo" instead of sizeof(foo)
> but now there is a new maintainer.
These days I run everything through checkpatch and generally don't
want to see much deviation from the 'normal' style, a few
On Mon, Sep 16, 2019 at 01:08:45PM -0400, Martin K. Petersen wrote:
> Vendor driver submissions, however, are generally huge. Sometimes 50+
> patches per submission window. And during this window I often get on the
> order of 10 to 20 patches for the same driver in the fixes tree. It is
> not alwa
Dan,
>> One pet peeve I have is that people are pretty bad at indicating the
>> intended target tree. I often ask for it in private mail but the
>> practice doesn't seem to stick. I spend a ton of time guessing whether a
>> patch is a fix for a new feature in the x+1 queue or a fix for the
>> cu
On Fri, 13 Sep 2019, Dan Carpenter wrote:
> And the documentation doesn't help. For example, I knew people's rules
> about capitalizing the subject but I'd just forget. I say that if you
> can't be bothered to add it to checkpatch then it means you don't really
> care that strongly.
It would be
On Fri, Sep 13, 2019 at 05:44:39PM -0400, Martin K. Petersen wrote:
> One pet peeve I have is that people are pretty bad at indicating the
> intended target tree. I often ask for it in private mail but the
> practice doesn't seem to stick. I spend a ton of time guessing whether a
> patch is a fix f
Jens,
> Additionally, it would seem saner to standardize rules around when
> code is expected to hit the maintainers hands for kernel
> releases. Both yours and Martins deals with that, there really
> shouldn't be the need to have this specified in detail per sub-system.
Yeah. There is basicall
On Fri, Sep 13, 2019 at 11:42 AM Joe Perches wrote:
>
> On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote:
> > On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap wrote:
> > > On 9/13/19 4:48 AM, Dan Carpenter wrote:
> > >
> > > > > So I'm expecting to take this kind of stuff into Documentation/. My
Hi Randy,
On Fri, Sep 13, 2019 at 5:00 PM Randy Dunlap wrote:
> On 9/13/19 4:48 AM, Dan Carpenter wrote:
> >> So I'm expecting to take this kind of stuff into Documentation/. My own
> >> personal hope is that it can maybe serve to shame some of these "local
> >> quirks" out of existence. The ev
On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap wrote:
> > On 9/13/19 4:48 AM, Dan Carpenter wrote:
> >
> > > > So I'm expecting to take this kind of stuff into Documentation/. My own
> > > > personal hope is that it can maybe serve to shame s
On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap wrote:
>
> On 9/13/19 4:48 AM, Dan Carpenter wrote:
>
> >> So I'm expecting to take this kind of stuff into Documentation/. My own
> >> personal hope is that it can maybe serve to shame some of these "local
> >> quirks" out of existence. The evidence
On 9/13/19 4:48 AM, Dan Carpenter wrote:
>> So I'm expecting to take this kind of stuff into Documentation/. My own
>> personal hope is that it can maybe serve to shame some of these "local
>> quirks" out of existence. The evidence from this brief discussion suggests
>> that this might indeed ha
On Fri, Sep 13, 2019 at 4:49 AM Dan Carpenter wrote:
>
> On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote:
> > On Wed, 11 Sep 2019 16:11:29 -0600
> > Jens Axboe wrote:
> >
> > > On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > > >
> > > > I kind of hate all this extra documentation be
On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote:
> On Wed, 11 Sep 2019 16:11:29 -0600
> Jens Axboe wrote:
>
> > On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > >
> > > I kind of hate all this extra documentation because now everyone thinks
> > > they can invent new hoops to jump th
On Wed, 11 Sep 2019 16:11:29 -0600
Jens Axboe wrote:
> On 9/11/19 12:43 PM, Dan Carpenter wrote:
> >
> > I kind of hate all this extra documentation because now everyone thinks
> > they can invent new hoops to jump through.
>
> FWIW, I completely agree with Dan (Carpenter) here. I absolutely
On Fri, Sep 13, 2019 at 07:41:55AM +0530, Aneesh Kumar K.V wrote:
> On 9/12/19 12:13 AM, Dan Carpenter wrote:
> > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> > > +Coding Style Addendum
> > > +-
> > > +libnvdimm expects multi-line statements to be double inden
On 9/12/19 12:13 AM, Dan Carpenter wrote:
On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
+Coding Style Addendum
+-
+libnvdimm expects multi-line statements to be double indented. I.e.
+
+if (x...
+&& ...y) {
That looks horrible
On Thu, 2019-09-12 at 07:17 -0700, Dan Williams wrote:
> Ok, good to confirm that we do not yet have an objective standard for
> coding style. This means it's not yet something process documentation
> can better standardize for contributors and will be subject to ongoing
> taste debates. Lets recl
On Thu, Sep 12, 2019 at 12:18 PM Joe Perches wrote:
>
> I don't think that's close to true yet for clang-format.
I don't expect clang-format to match perfectly our current code style.
However, if core maintainers agree that it is "close enough now"
(specially with newer LLVMs, like 9), then ther
On Thu, Sep 12, 2019 at 4:02 AM Joe Perches wrote:
>
> (cut down the cc-list)
>
> On Thu, 2019-09-12 at 03:18 -0700, Joe Perches wrote:
> > On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> > > On Thu, Sep 12, 2019 at 9:43 AM Dan Williams
> > > wrote:
> > > > Now I come to find that Codin
On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> On Thu, Sep 12, 2019 at 9:43 AM Dan Williams wrote:
> > Now I come to find that CodingStyle has settled on clang-format (in
> > the last 15 months) as the new standard which is a much better answer
> > to me than a manually specified style o
On Thu, Sep 12, 2019 at 9:43 AM Dan Williams wrote:
>
> Now I come to find that CodingStyle has settled on clang-format (in
> the last 15 months) as the new standard which is a much better answer
> to me than a manually specified style open to interpretation. I'll
> take a look at getting libnvdim
On Wed, Sep 11, 2019 at 3:11 PM Jens Axboe wrote:
>
> On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> >> +Coding Style Addendum
> >> +-
> >> +libnvdimm expects multi-line statements to be double indented. I.e.
> >> +
On 9/11/19 12:43 PM, Dan Carpenter wrote:
> On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
>> +Coding Style Addendum
>> +-
>> +libnvdimm expects multi-line statements to be double indented. I.e.
>> +
>> +if (x...
>> +&& ...y) {
>
>
On Wed, 2019-09-11 at 08:48 -0700, Dan Williams wrote:
> Document the basic policies of the libnvdimm subsystem and provide a first
> example of a Maintainer Entry Profile for others to duplicate and edit.
[]
> +Coding Style Addendum
> +-
> +libnvdimm expects multi-line statemen
On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> +Coding Style Addendum
> +-
> +libnvdimm expects multi-line statements to be double indented. I.e.
> +
> +if (x...
> +&& ...y) {
That looks horrible and it causes a checkpatch warnin
> Document the basic policies of the libnvdimm subsystem and provide a first
> example of a Maintainer Entry Profile for others to duplicate and edit.
>
> Cc: Vishal Verma
> Cc: Dave Jiang
> Signed-off-by: Dan Williams
> ---
> Documentation/nvdimm/maintainer-entry-profile.rst | 64
> +++
27 matches
Mail list logo