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 23:58 +0200, Miguel Ojeda wrote:
> On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
> > Marking sections _no_auto_format_ isn't really a
> > good solution is it?
>
> I am thinking about special tables that are hand-crafted or very
> complex macros. For those, yes, I thin
On Thu, 2019-09-12 at 16:00 -0700, Nick Desaulniers wrote:
> Consider the fact that not all kernel developers run checkpatch.pl.
> Is that a deficiency in checkpatch.pl, or the lack of enforcement in
> kernel developers' workflows?
No. Mostly it's because the kernel is like a bunch of little
unt
On Thu, Sep 12, 2019 at 3:38 PM Joe Perches wrote:
>
> On Thu, 2019-09-12 at 23:58 +0200, Miguel Ojeda wrote:
> > On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
> > > Please name the major projects and then point to their
> > > .clang-format equivalents.
> > >
> > > Also note the size/scope/
On Thu, Sep 12, 2019 at 2:58 PM Miguel Ojeda
wrote:
>
> On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
> >
> > Please name the major projects and then point to their
> > .clang-format equivalents.
> >
> > Also note the size/scope/complexity of the major projects.
>
> Mozilla, WebKit, LLVM an
On Thu, 2019-09-12 at 23:58 +0200, Miguel Ojeda wrote:
> On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
> > Please name the major projects and then point to their
> > .clang-format equivalents.
> >
> > Also note the size/scope/complexity of the major projects.
>
> Mozilla, WebKit, LLVM and
On Thu, 2019-09-12 at 23:58 +0200, Miguel Ojeda wrote:
> On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
> > Please name the major projects and then point to their
> > .clang-format equivalents.
> >
> > Also note the size/scope/complexity of the major projects.
>
> Mozilla, WebKit, LLVM and
On Thu, Sep 12, 2019 at 11:08 PM Joe Perches wrote:
>
> Please name the major projects and then point to their
> .clang-format equivalents.
>
> Also note the size/scope/complexity of the major projects.
Mozilla, WebKit, LLVM and Microsoft. They have their style distributed
with the official clang
On Thu, 2019-09-12 at 16:21 +0200, Miguel Ojeda wrote:
> As soon as you get accustomed to have formatting done and enforced
> automatically, it is great. Other major projects have done so for
> quite a while now.
Please name the major projects and then point to their
.clang-format equivalents.
A
On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote:
> Another argument in favor of W=1 is that the formatting of kernel-doc
> headers is checked only if W=1 is passed to make.
Actually, but for the fact there are far too many
to generally enable that warning right now,
(an x86-64 defconfig
On 9/12/19 8:34 AM, Joe Perches wrote:
> On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:
>> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
>>> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
>>> and does not incur any zeroday test robot complaints.
>>
>> How
On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:
> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> > * Do not use custom To: and Cc: for individual patches. We want to see the
> > whole series, even patches that potentially need to go through a different
> > subsystem tree.
That's not
On Thu, 2019-09-12 at 05:17 -0700, Christoph Hellwig wrote:
> Instead of arguing what is better just stick to what the surrounding
> code does.
That's not always feasible nor readable.
Especially for the logic inversion blocks where
the existing code does unreadable and error prone
things like hi
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 7:06 AM Johannes Thumshirn wrote:
>
> On 12/09/2019 16:00, Jeff Moyer wrote:
> > I'd rather avoid the churn and the risk of
> > introducing regressions. This will also make backports to stable more
> > of a pain, so it isn't without cost. Dan, is this really something you
On Thu, Sep 12, 2019 at 4:00 PM Jeff Moyer wrote:
>
> Joe Perches writes:
>
> > Rather than have a local coding style, use the typical kernel style.
>
> The coding style isn't that different from the core kernel, and it's
> still quite readable. I'd rather avoid the churn and the risk of
> intro
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 12/09/2019 16:00, Jeff Moyer wrote:
> I'd rather avoid the churn and the risk of
> introducing regressions. This will also make backports to stable more
> of a pain, so it isn't without cost. Dan, is this really something you
> want to do?
I'm a 100% with Jeff on this!
--
Johannes Thumshirn
Joe Perches writes:
> Rather than have a local coding style, use the typical kernel style.
The coding style isn't that different from the core kernel, and it's
still quite readable. I'd rather avoid the churn and the risk of
introducing regressions. This will also make backports to stable more
On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> * Do not use custom To: and Cc: for individual patches. We want to see the
> whole series, even patches that potentially need to go through a different
> subsystem tree.
Hi Martin,
Thanks for having written this summary. This is very helpful. Fo
On 9/11/19 4:48 PM, Dan Williams wrote:
> At last years Plumbers Conference I proposed the Maintainer Entry
> Profile as a document that a maintainer can provide to set contributor
> expectations and provide fodder for a discussion between maintainers
> about the merits of different maintainer poli
> static void append_badrange_entry(struct badrange *badrange,
> - struct badrange_entry *bre, u64 addr, u64 length)
> + struct badrange_entry *bre, u64 addr, u64
> length)
Please stop sending this kind of crap. Two tabs are a very common
style used in
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 10:15 AM Joe Perches wrote:
>
> I am adding Miguel Ojeda to the cc's.
Thanks Joe!
> Of course you are welcome to try it, but I believe that
> clang-format doesn't work all that well yet.
>
> It's more a work in progress rather than a "standard".
>
> I believe you'll find
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 Thu, 2019-09-12 at 01:00 -0700, Dan Williams wrote:
> Hi Joe,
>
> On Wed, Sep 11, 2019 at 7:55 PM Joe Perches wrote:
> > Rather than have a local coding style, use the typical kernel style.
>
> I'd rather automate this. I'm going to do once-over with clang-format
> and see what falls out.
I
Hi Joe,
On Wed, Sep 11, 2019 at 7:55 PM Joe Perches wrote:
>
> Rather than have a local coding style, use the typical kernel style.
I'd rather automate this. I'm going to do once-over with clang-format
and see what falls out.
___
Linux-nvdimm mailing l
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.
> >> +
30 matches
Mail list logo
