On Tue, 2023-10-10 at 14:58 +0200, Max Kellermann wrote:
> There are currently no rules on the placement of "const", but a recent
> code submission revealed that there is clearly a preference for spaces
> around it.
>
> checkpatch.pl has no check at all for this; though it does sometimes
> complai
On Thu, 2023-10-12 at 13:50 +0200, Miguel Ojeda wrote:
> On Wed, 11 Oct 2023 14:44:17 -0700, Dan Williams wrote:
> >
> > I notice that clang-format reflows that example to:
> >
> > const void *a;
> > void *const b;
> > void **const c;
> > void *const *const d;
> > int strcmp(c
On Mon, 2023-10-23 at 16:16 +0200, Lukas Bulwahn wrote:
> On Mon, Oct 23, 2023 at 12:29 PM Przemek Kitszel
> wrote:
> > Allow additional tags between Co-developed-by: and Signed-off-by:.
I think this unnecessary and not particularly useful as well.
>
> I see many potential areas of work for th
On Thu, 2024-03-28 at 15:21 +1300, Barry Song wrote:
> From: Xining Xu
>
> If function-like macros do not utilize a parameter, it might result in a
> build warning. In our coding style guidelines, we advocate for utilizing
> static inline functions to replace such macros. This patch verifies
>
On Sat, 2024-03-30 at 00:08 +0100, Charlemagne Lasse wrote:
> Hi,
>
> Can this patch please be dropped from Linux-next (currently via
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm#mm-everything)?
> It is obviously wrong when dealing with named variadic macro
> parameters:
I agree it was
On Sun, 2024-03-31 at 13:46 +, Mac Xu wrote:
> > On Thu, 2024-03-28 at 15:21 +1300, Barry Song wrote:
> > > From: Xining Xu
> > >
> > > If function-like macros do not utilize a parameter, it might result in a
> > > build warning. In our coding style guidelines, we advocate for utilizing
> >
On Mon, 2024-04-01 at 14:21 +1300, Barry Song wrote:
> From: Xining Xu
>
> If function-like macros do not utilize a parameter, it might result in a
> build warning. In our coding style guidelines, we advocate for utilizing
> static inline functions to replace such macros. This patch verifies
>
On Tue, 2024-04-02 at 00:16 +, Mac Xu wrote:
> > On Mon, 2024-04-01 at 14:21 +1300, Barry Song wrote:
> > > From: Xining Xu
> > >
> > > If function-like macros do not utilize a parameter, it might result in a
> > > build warning. In our coding style guidelines, we advocate for utilizing
> >
gt; changes without some serious acks on them - nobody elected me as the
> > arbiter of proper coding style.
I believe it is generally appropriate for macros that take
arguments to use static inlines where feasible, so:
Acked-by: Joe Perches
And yes, mm is the usual path for upstreaming at least this
sort of checkpatch change.
f ($define_stmt !~ /\b$arg\b/) {
> + WARN("MACRO_ARG_UNUSED",
> + "Argument '$arg' is not used in
> function-like macro\n" . "$herectx");
trivia: This should be aligned to the open parenthesis.
Otherwise:
Acked-by: Joe Perches
/\b$arg\b/) {
> WARN("MACRO_ARG_UNUSED",
> - "Argument '$arg' is not used in
> function-like macro\n" . "$herectx");
> + "Argument '$arg' is not used in
> function-like macro\n" . "$herectx");
> }
> }
> > Otherwise:
> > Acked-by: Joe Perches
Yes, but please send a v7 instead of a separate patch
to akpm or perhaps Andrew could combine them or fix it
when applying v6
On Thu, 2019-07-04 at 11:24 +0530, Nitin Gote wrote:
> Added warnings in checkpatch.pl script to :
>
> 1. Deprecate strcpy() in favor of strscpy().
> 2. Deprecate strlcpy() in favor of strscpy().
> 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad().
>
> Updated strncpy() section in Doc
On Thu, 2019-07-04 at 13:46 -0700, Joe Perches wrote:
> On Thu, 2019-07-04 at 11:24 +0530, Nitin Gote wrote:
> > Added warnings in checkpatch.pl script to :
> >
> > 1. Deprecate strcpy() in favor of strscpy().
> > 2. Deprecate strlcpy() in favor of strscpy().
> >
On Tue, 2019-07-09 at 11:10 +0530, NitinGote wrote:
> From: Nitin Gote
>
> 1. Deprecate strcpy() in favor of strscpy().
> 2. Deprecate strlcpy() in favor of strscpy().
> 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad().
>
> Updated strncpy() section in Documentation/process/deprecat
On Tue, 2019-07-09 at 21:18 +0530, NitinGote wrote:
> From: Nitin Gote
>
> 1. Deprecate strcpy() in favor of strscpy().
> 2. Deprecate strlcpy() in favor of strscpy().
> 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad().
>
> Updated strncpy() section in Documentation/process/deprecat
On Mon, 2019-07-22 at 10:30 -0700, Kees Cook wrote:
> On Wed, Jul 17, 2019 at 10:00:05AM +0530, NitinGote wrote:
> > From: Nitin Gote
> >
> > Added check in checkpatch.pl to
> > 1. Deprecate strcpy() in favor of strscpy().
> > 2. Deprecate strlcpy() in favor of strscpy().
> > 3. Deprecate strncpy
On Mon, 2019-07-22 at 10:33 -0700, Kees Cook wrote:
> On Thu, Jul 04, 2019 at 05:15:57PM -0700, Joe Perches wrote:
> > On Thu, 2019-07-04 at 13:46 -0700, Joe Perches wrote:
> > > On Thu, 2019-07-04 at 11:24 +0530, Nitin Gote wrote:
> > > > Added warni
On Mon, 2019-07-22 at 10:43 -0700, Joe Perches wrote:
> On Mon, 2019-07-22 at 10:33 -0700, Kees Cook wrote:
> > On Thu, Jul 04, 2019 at 05:15:57PM -0700, Joe Perches wrote:
> > > On Thu, 2019-07-04 at 13:46 -0700, Joe Perches wrote:
> > > > On Thu, 2019-07-04 at
On Mon, 2019-07-22 at 11:27 -0700, Matthew Wilcox wrote:
> On Mon, Jul 22, 2019 at 10:58:15AM -0700, Joe Perches wrote:
> > On Mon, 2019-07-22 at 10:43 -0700, Joe Perches wrote:
> > > On Mon, 2019-07-22 at 10:33 -0700, Kees Cook wrote:
> > > > On Thu, Jul 04, 2019 at
core-api should show all the various string functions including the
newly added stracpy and stracpy_pad.
Miscellanea:
o Update the Returns: value for strscpy
o fix a defect with %NUL)
Signed-off-by: Joe Perches
---
Documentation/core-api/kernel-api.rst | 3 +++
include/linux/string.h
Add more string copy mechanisms to help avoid defects
Joe Perches (2):
string: Add stracpy and stracpy_pad mechanisms
kernel-doc: core-api: Include string.h into core-api
Documentation/core-api/kernel-api.rst | 3 +++
include/linux/string.h| 46
core-api should show all the various string functions including the
newly added stracpy and stracpy_pad.
Miscellanea:
o Update the Returns: value for strscpy
o fix a defect with %NUL)
Signed-off-by: Joe Perches
---
V2: Correct return of -E2BIG descriptions
Documentation/core-api/kernel
Add more string copy mechanisms to help avoid defects
Joe Perches (2):
string: Add stracpy and stracpy_pad mechanisms
kernel-doc: core-api: Include string.h into core-api
Documentation/core-api/kernel-api.rst | 3 +++
include/linux/string.h| 50
On Wed, 2019-07-24 at 18:17 +, Gote, Nitin R wrote:
> Hi,
Hi again.
[]
> > > > > 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad().
Please remember there does not exist a single actual use
of strscpy_pad in the kernel sources and no apparent real
need for it. I don't find one an
On Thu, 2019-07-25 at 11:50 -0700, Kees Cook wrote:
> On Thu, Jul 25, 2019 at 04:52:19PM +0530, NitinGote wrote:
> > From: Nitin Gote
> >
> > Added check in checkpatch.pl to deprecate strcpy(), strlcpy() and
> > strncpy() in favor of stracpy().
>
> stracpy() is preferred when the destination is
On Thu, 2019-07-25 at 16:52 +0530, NitinGote wrote:
> From: Nitin Gote
>
> Added check in checkpatch.pl to deprecate strcpy(), strlcpy() and
> strncpy() in favor of stracpy().
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> +our %deprecated_string_apis = (
> + "strcpy"
On Tue, 2019-08-27 at 23:12 +0200, Uwe Kleine-König wrote:
> The new format specifier %dE introduced with this patch pretty-prints
> the typical negative error values. So
>
> pr_info("probing failed (%dE)\n", ret);
>
> yields
>
> probing failed (EIO)
>
> if ret holds -EIO. This is e
On Tue, 2019-08-27 at 23:35 +0200, Uwe Kleine-König wrote:
> Hello Joe,
>
> On 8/27/19 11:22 PM, Joe Perches wrote:
> > On Tue, 2019-08-27 at 23:12 +0200, Uwe Kleine-König wrote:
> > > The new format specifier %dE introduced with this patch pretty-prints
> > >
On Thu, 2019-09-05 at 09:07 -0300, Mauro Carvalho Chehab wrote:
> There are currently 227 files that don't complain with the "up to line 3"
> rule, including COPYING (with should probably be excluded from the check).
>
> Patches are at:
>
> https://git.linuxtv.org/mchehab/experimental.git/l
On Thu, 2019-09-05 at 16:57 -0300, Mauro Carvalho Chehab wrote:
> The description at Documentation/process/license-rules.rst is very strict
> with regards to the position where the SPDX tags should be.
[]
> PS.: I sent already a RFC version for those patches along with this
> thread:
>
>
> h
On Fri, 2019-09-06 at 08:34 -0300, Mauro Carvalho Chehab wrote:
> I did some changes on it, plus one change at the pedantic mode of
> scripts/spdxcheck.py, and placed the corresponding patches at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=spdx_pedantic
Overall seems very n
On Fri, 2019-09-06 at 09:02 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 05 Sep 2019 13:05:08 -0700
> Joe Perches escreveu:
>
> > On Thu, 2019-09-05 at 16:57 -0300, Mauro Carvalho Chehab wrote:
> > > The description at Documentation/process/license-rules.rst is very s
On Fri, 2019-09-06 at 11:45 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 06 Sep 2019 05:20:30 -0700
> Joe Perches escreveu:
>
> > On Fri, 2019-09-06 at 08:34 -0300, Mauro Carvalho Chehab wrote:
> > > I did some changes on it, plus one change at the pedantic mode of
&g
On Fri, 2019-09-06 at 08:34 -0300, Mauro Carvalho Chehab wrote:
> I did some changes on it, plus one change at the pedantic mode of
> scripts/spdxcheck.py, and placed the corresponding patches at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=spdx_pedantic
Your script needs a
On Fri, 2019-09-06 at 08:34 -0300, Mauro Carvalho Chehab wrote:
> Warning: SPDX header for file tools/thermal/tmon/tmon.8 is at line 2
[]
> The last one is interesting... what's the "very first line" where a
> SPDX header tag should be on a man page?
just fyi:
It looks like .man pages could use a
On Fri, 2019-09-06 at 15:17 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 06 Sep 2019 10:33:42 -0700
> Joe Perches escreveu:
>
> > On Fri, 2019-09-06 at 08:34 -0300, Mauro Carvalho Chehab wrote:
> > > I did some changes on it, plus one change at the pedantic mode of
&g
nestly, that is a really bad reason, you'd be better off
just using a proper cast to make the code more obvious).
So if what you have a "char" (or unsigned char) you should always just
print it out as an "int", knowing that the compiler already did the
proper type conve
On Tue, 2019-09-10 at 18:26 +0300, Andy Shevchenko wrote:
> On Mon, Sep 9, 2019 at 11:39 PM Rasmus Villemoes
> wrote:
> > It has been suggested several times to extend vsnprintf() to be able
> > to convert the numeric value of ENOSPC to print "ENOSPC". This is yet
> > another attempt. Rather than
On Wed, 2019-09-11 at 17:37 -0300, André Almeida wrote:
> "Busses" is the third person conjugation of verb "to buss" in the
> present tense. "Buses" is the plural of bus, as in "serial bus".
busses and buses are both acceptable plurals of bus
https://www.dictionary.com/browse/bus
On Tue, 2019-09-10 at 15:17 +0200, Federico Vaga wrote:
> Generally speaking compactness does not bring any value if then the text is
> unclear or open to interpretation.
It's somewhat difficult to choose between +1 and I agree.
pt_regs *regs,
case 0xe8e0:
case 0xe9e0:
poffset->un = (tinst2 & 0xff) << 2;
- /* Fall through */
-
+ fallthrough;
case 0xe940:
case 0xe9c0:
return do_alignment_ldrdstrd;
Joe Perches (4):
net: sct
Describe the fallthrough pseudo-keyword.
Convert the coding-style.rst example to the keyword style.
Add description and links to deprecated.rst.
Signed-off-by: Joe Perches
---
Documentation/process/coding-style.rst | 2 +-
Documentation/process/deprecated.rst | 33
On Fri, 2019-10-11 at 09:29 -0700, Linus Torvalds wrote:
> On Sat, Oct 5, 2019 at 9:46 AM Joe Perches wrote:
> > Add 'fallthrough' pseudo-keyword to enable the removal of comments
> > like '/* fallthrough */'.
>
> I applied patches 1-3 to my tree jus
On Fri, 2019-10-11 at 10:46 -0700, Linus Torvalds wrote:
> On Fri, Oct 11, 2019 at 10:43 AM Joe Perches wrote:
> > Shouldn't a conversion script be public somewhere?
>
> I feel the ones that might want to do the conversion on their own are
> the ones that don't
On Mon, 2019-10-14 at 13:47 -0700, John Hubbard wrote:
> Hi,
>
> When adding a new Documentation/ file, checkpatch.pl is warning me
> that the SPDX tag is missing. Should checkpatch.pl skip those kinds
> of warnings, seeing as how we probably don't intend on putting the
> SPDX tags at the top of t
On Mon, 2019-03-04 at 09:59 -0800, Nick Desaulniers wrote:
> On Sun, Mar 3, 2019 at 12:10 PM Andy Shevchenko
> wrote:
> > On Sun, Mar 03, 2019 at 12:36:47PM +, Louis Taylor wrote:
> > > A few commonly used integer types were absent from this table, so add
> > > them.
> >
> > I'm not against t
On Tue, 2019-03-05 at 12:07 -0800, Matthew Wilcox wrote:
> On Tue, Mar 05, 2019 at 11:59:30AM -0800, Joe Perches wrote:
> > Many of the -Wformat warnings are bogus too.
> >
> > There's nothing wrong with using %x for a unsigned int
> > of less than long size. (
On Sun, 2019-05-12 at 20:50 +0800, Changbin Du wrote:
> This converts the plain text documentation to reStructuredText format and
> add it to Sphinx TOC tree. No essential content change.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -12100,7 +12100,7 @@ M:Sam Bobroff
> M: Oliver O'Ha
On Wed, 2019-05-22 at 20:36 +0200, Pavel Machek wrote:
> On Tue 2019-05-21 17:54:30, Lukas Prause wrote:
> > This patch corrects renamed or moved paths in comments.
> >
> > Signed-off-by: Lukas Prause
> > Signed-off-by: Lennart Glauer
>
> Acked-by: Pavel Machek
>
> > diff --git a/kernel/power
On Thu, 2019-06-27 at 14:46 -0700, tip-bot for Mauro Carvalho Chehab
wrote:
> Commit-ID: 516337048fa40496ae5ca9863c367ec991a44d9a
> Gitweb:
> https://git.kernel.org/tip/516337048fa40496ae5ca9863c367ec991a44d9a
> Author: Mauro Carvalho Chehab
> AuthorDate: Mon, 24 Jun 2019 07:33:26 -0300
On Thu, 2019-06-27 at 21:39 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 27 Jun 2019 15:08:59 -0700
> Joe Perches escreveu:
[]
> > > hrtimer: Use a bullet for the returns bullet list
> > >
> > > That gets rid of this warning:
> > >
> > >
On Fri, 2019-06-28 at 09:12 -0300, Mauro Carvalho Chehab wrote:
> That gets rid of this warning:
>
> ./kernel/time/hrtimer.c:1119: WARNING: Block quote ends without a blank
> line; unexpected unindent.
>
> and displays nicely both at the source code and at the produced
> documentation.
>
Make these files symlinks to the .rst equivalents
Signed-off-by: Joe Perches
---
Documentation/CodingStyle | 2 +-
Documentation/SubmittingPatches | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
mode change 100644 => 12 Documentation/CodingStyle
mode change 100644 =>
On Wed, 2017-01-11 at 10:54 +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2017, Joe Perches wrote:
> > Make these files symlinks to the .rst equivalents
>
> If we're going to do this (and I really don't mind either way), then
> please add
>
> Fixes: 08a9a8d4
On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
> On Tue, 10 Jan 2017 14:09:51 -0800
> Joe Perches wrote:
>
> > Make these files symlinks to the .rst equivalents
>
> So I am not necessarily opposed to doing this, but the changelog lacks
> one important thing
On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
> We have a device reference, utilize it instead of pr_warn().
There is at least one more hwmon to convert in applesmc.c
Perhaps a coccinelle script?
Two questions for Julia Lawall:
o is there a better way to do this than repeat the blo
On Sun, 2017-01-22 at 22:43 -0800, Joe Perches wrote:
> Two questions for Julia Lawall:
>
> o is there a better way to do this than repeat the blocks
> one for each replacement
> o can struct device * dev be made an arbitrary identifier
>
> $ cat dev_printk.cocci
> @@
&
On Mon, 2017-01-23 at 11:44 +0100, Geert Uytterhoeven wrote:
> When will/can we get rid of them?
> Old (doh) kernels, and new versions of stable kernels will keep on having
> them for the next +10 years.
>
> To me, these[*] filenames are more like a user-visible API, which should
> not be changed
(adding Greg KH as I doubt he ever saw the original)
On Tue, 2017-02-14 at 14:34 -0700, Jonathan Corbet wrote:
> On Mon, 23 Jan 2017 08:34:58 -0200
> Mauro Carvalho Chehab wrote:
>
> > The main difference between a "pointer file" and a symlink is that the
> > first indicates a temporary solution
On Tue, 2017-04-18 at 23:53 +0200, Peter Rosin wrote:
> On 2017-04-18 13:44, Greg Kroah-Hartman wrote:
> > On Tue, Apr 18, 2017 at 12:59:50PM +0200, Peter Rosin wrote:
[]
> > > > > + ret = device_add(&mux_chip->dev);
> > > > > + if (ret < 0)
> > > > > + dev_err(&mux_chip->dev,
>
On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - add a title
On Tue, 2017-06-06 at 16:53 +0200, Greg KH wrote:
> On Tue, Jun 06, 2017 at 04:49:09PM +0200, Greg KH wrote:
> > I noticed that in drivers/staging/unisys/visorbus/visorbus_main.c, you
> > have 2 tabs for your 'struct attribute' variables, which is really odd.
[]
> Also, many of the attribute callba
On Tue, 2017-06-06 at 17:39 +0200, Greg KH wrote:
> On Tue, Jun 06, 2017 at 08:33:49AM -0700, Joe Perches wrote:
> > On Tue, 2017-06-06 at 16:53 +0200, Greg KH wrote:
> > > On Tue, Jun 06, 2017 at 04:49:09PM +0200, Greg KH wrote:
> > > > I noticed that in d
On Wed, 2017-12-06 at 08:11 +0100, Markus Heiser wrote:
> > Am 06.12.2017 um 02:45 schrieb Tobin C. Harding :
> > Documentation/printk-formats.txt is a candidate for conversion to
> > ReStructuredText format. Some effort has already been made to do this
> > conversion even thought the suffix is cur
On Fri, 2017-12-08 at 08:21 +1100, Tobin C. Harding wrote:
> On Thu, Dec 07, 2017 at 01:52:56PM -0700, Jonathan Corbet wrote:
> > On Fri, 8 Dec 2017 07:44:34 +1100
> > "Tobin C. Harding" wrote:
> >
> > > Where is Jon's tree hosted please, I don't see it on kernel.org
> >
> > From the MAINTAINERS
On Fri, 2017-12-08 at 13:06 -0800, Kees Cook wrote:
> Well ... my sense is that lib/vsprintf.c should remain the canonical
> documentation.
I agree.
> Anyone working on the code has the docs all together in
> one file. If it helps the .rst file to reformat the comments into
> kernel-doc, that's f
On Sat, 2017-12-09 at 12:27 +1100, Tobin C. Harding wrote:
> On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote:
> > Outside of the documentation, what could be useful is for
> > someone to add a tool to verify %p extension to
> > the typeof address actually
On Sat, 2017-12-16 at 15:42 +0100, Knut Omang wrote:
> This patch series implements features to make it easier to run checkers on the
> entire kernel as part of automatic and developer testing.
This seems like a useful and reasonable series, thanks.
Do please take Julia's grammar updates.
How is
On Sat, 2017-12-16 at 17:27 +0100, Knut Omang wrote:
> On Sat, 2017-12-16 at 07:21 -0800, Joe Perches wrote:
> > On Sat, 2017-12-16 at 15:42 +0100, Knut Omang wrote:
> > > This patch series implements features to make it easier to run checkers
> > > on the
> > >
On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:25 +0100
> Knut Omang wrote:
>
> > This patch series implements features to make it easier to run checkers on
> > the
> > entire kernel as part of automatic and developer testing.
> >
> > This is done by rep
On Mon, 2017-12-18 at 09:30 +1100, Tobin C. Harding wrote:
> This set converts printk-formats.txt -> core-api/printk-formats.rst
>
> We also update the documentation around printing kernel addresses.
Please also update the comment in lib/vsprintf.c
* ** Please update also Documentation/printk-f
On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
>
> > > I like the ability to add more checkers and keep then in the main
> > > upstream tree. But adding overrides for specific subsystems goes against
> > > the policy that all
On Mon, 2017-12-18 at 14:05 +0100, Knut Omang wrote:
> > Here is a list of the checkpatch messages for drivers/infiniband
> > sorted by type.
> >
> > Many of these might be corrected by using
> >
> > $ ./scripts/checkpatch.pl -f --fix-inplace --types= \
> > $(git ls-files drivers/infiniband/)
>
On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
>
> > > Today when we run checkers we get so many warnings it is too hard to
> > > make any sense of it.
> >
> > Here is a list of
On Thu, 2017-12-21 at 12:21 -0700, Jonathan Corbet wrote:
> On Wed, 20 Dec 2017 08:17:14 +1100
> "Tobin C. Harding" wrote:
>
> > This set converts printk-formats.txt -> core-api/printk-formats.rst
> >
> > We also update the documentation around printing kernel addresses.
[]
> > - There's a dang
On Sun, 2018-01-14 at 20:10 +, Al Viro wrote:
> On Sun, Jan 14, 2018 at 11:47:11PM +0530, Naveen Panwar wrote:
> > Removed '(' from the end of line, coding style issue.
>
> The one and only reason for warnings is that they point to
> places more likely to be dodgy. There is no inherent value
On Wed, 2018-02-21 at 16:37 -0800, Kees Cook wrote:
> As recently pointed out by Linus, "Root-caused-by" is a good tag to include
> since it can indicate significantly more work than "just" a Reported-by.
> This adds it and "Suggested-by" (which was also missing) to the documented
> list of tags. A
On Thu, 2018-02-22 at 10:40 -0700, Jonathan Corbet wrote:
> That said, we can add this one; I'll take the patch if I get an ack from
> Joe.
Meh-ed-by: Joe Perches
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...
On Mon, 2018-03-05 at 14:58 +1100, Tobin C. Harding wrote:
> From: Joe Perches
I still think this "Co-Developed-by" stuff is unnecessary.
> Recently signature tag Co-Developed-by was added to the
> kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't
On Thu, 2018-03-15 at 10:48 +0100, Geert Uytterhoeven wrote:
> Hi David,
>
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote:
> > Do we have anything left that still implements NOMMU?
>
> Sure: arm, c6x, m68k, microblaze, and sh.
I have a patchset that creates a vsprintf extension for
pr
On Thu, 2018-03-15 at 10:08 -0700, Matthew Wilcox wrote:
> On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote:
> > I have a patchset that creates a vsprintf extension for
> > print_vma_addr and removes all the uses similar to the
> > print_symbol() removal.
> &g
On Fri, 2018-12-14 at 12:16 -0800, Andrew Morton wrote:
> On Fri, 14 Dec 2018 18:35:28 +0100 Jorge Ramirez-Ortiz
> wrote:
>
> > As per Documentation/process/submitting-patches, Co-developed-by is a
> > valid signature.
> >
>
> I'm with Joe - I find this tag kinda useless and duplicative. But
On Fri, 2019-01-04 at 09:41 -0700, Jonathan Corbet wrote:
> On Fri, 04 Jan 2019 08:32:38 -0800
> Bart Van Assche wrote:
> > > Isn't it better if we collect such configuration files into a dedicated
> > > directory (where exactly?) instead of putting them in the top-level one?
> > > Then,
> > >
On Mon, 2019-01-07 at 10:20 -0800, Bart Van Assche wrote:
> In emacs 23.1 support for directory-local variables was added (see also
> https://lists.gnu.org/archive/html/info-gnu-emacs/2009-07/msg0.html).
> Simplify the settings in coding-style.rst by using that feature.
> Additionally, do not i
On Thu, 2019-02-07 at 18:18 +0200, Mike Rapoport wrote:
> Hi Markus,
>
> On Thu, Feb 07, 2019 at 04:58:17PM +0100, Markus Heiser wrote:
> > Am 07.02.19 um 16:30 schrieb Mike Rapoport:
> > > On Thu, Feb 07, 2019 at 05:59:24AM -0800, Matthew Wilcox wrote:
> > > > This seems to be an extremely common
On Thu, 2019-02-07 at 09:34 -0800, Matthew Wilcox wrote:
> On Thu, Feb 07, 2019 at 09:31:20AM -0800, Joe Perches wrote:
> > It's not clear to me what you are asking checkpatch to do here.
> >
> > It may be reasonable for checkpatch to invoke kernel-doc on some
> >
On Thu, 2019-02-07 at 18:58 +0100, Markus Heiser wrote:
> Am 07.02.19 um 18:50 schrieb Joe Perches:
> > On Thu, 2019-02-07 at 09:34 -0800, Matthew Wilcox wrote:
> > > On Thu, Feb 07, 2019 at 09:31:20AM -0800, Joe Perches wrote:
> > > > It's not clear to me what y
On Thu, 2017-10-19 at 13:35 +0200, SF Markus Elfring wrote:
> > > > > Omit an extra message for a memory allocation failure in this
> > > > > function.
> > > > >
> > > > > This issue was detected by using the Coccinelle software.
[]
> > > Do you see any need that I should extend subsequent commit
On Fri, 2016-09-16 at 11:10 -0600, Jonathan Corbet wrote:
> On Wed, 14 Sep 2016 08:06:34 -0300 Mauro Carvalho Chehab
> wrote:
> - use the correct markup to identify each section;
> - Add some blank lines for Sphinx to properly interpret
> the markups;
> - Remove a blank space on some paragraphs
On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote:
> IMO what we need is to go through all rules in CodingStyle and if for
> some rule there is no overwhelming majority in the core kernel, well,
> the list has grown way too large and could use massive trimming.
I'm in complete agreement.
I also th
On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote:
> On Mon, 19 Sep 2016, Joe Perches wrote:
> > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote:
> > > IMO what we need is to go through all rules in CodingStyle and if for
> > > some rule there is no overwhelming
On Wed, 2016-09-21 at 15:54 -0600, Jonathan Corbet wrote:
> Recent discussion has made it clear that there is no community consensus
> on this particular rule. Remove it now, lest it inspire yet another set
> of unwanted "cleanup" patches.
Thanks. I believe it's better to remove this one too.
--
On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote:
[]
> > The seriousness with which some beginners take these message
> > types though is troublesome,
[]
> You need to think in terms of actual use cases. Who uses checkpatch and
> why? I think there are 3 groups of users:
> * Beginners. They wo
On Thu, 2016-09-22 at 14:11 +0100, Al Viro wrote:
> The main intent of checkpatch these days appears to be providing an easy
> way of thoughtless inflation of commit counts, everything else be damned.
You've made this statement several times over many years.
I don't believe it's true.
I doubt anyo
On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote:
> Sure. But I'm afraid you keep changing topics and I have no idea where
> you are going. We started with "should there be a space before jump
> labels", then out of nowhere we were discussing the wording of the
> output of checkpatch (how is t
On Fri, 2016-09-23 at 12:07 -0300, Mauro Carvalho Chehab wrote:
> So, let's use an unusual approach: manually convert the
> text at the MAINTAINERS file head, adding it at a new
> Documentation/user/MAINTAINERS.rst, and include, as a code
> block, the rest of MAINTAINERS contents, with only the
> c
On Thu, 2016-10-06 at 14:00 -0700, Kees Cook wrote:
> And based on my read of this thread, we all appear to be in violent
> agreement. :) "always protect %p" is absolutely the goal, and we can
> figure out the best way to get there.
I proposed emitting pointers from the const and text sections by
On Mon, 2016-12-12 at 11:00 -0700, Jonathan Corbet wrote:
> On Fri, 2 Dec 2016 10:15:13 -0200
> Mauro Carvalho Chehab wrote:
>
> > On the past approaches, was planning to keep the documentation
> > about what's at the MAINTAINERS file inside it, but that would
> > require running an external scr
a, On Tue, 2016-12-13 at 09:19 +, Nicholas Mc Guire wrote:
> On Tue, Dec 13, 2016 at 11:10:50AM +0200, Jani Nikula wrote:
> > On Tue, 13 Dec 2016, Nicholas Mc Guire wrote:
> > > useleep_range() with a delta of 0 makes no sense and only prevents the
> > > timer subsystem from optimizing interru
On Wed, 2016-12-14 at 00:37 +, Nicholas Mc Guire wrote:
> On Tue, Dec 13, 2016 at 04:27:32PM -0800, Joe Perches wrote:
> > a, On Tue, 2016-12-13 at 09:19 +, Nicholas Mc Guire wrote:
> > > On Tue, Dec 13, 2016 at 11:10:50AM +0200, Jani Nikula wrote:
> > > > On
1 - 100 of 123 matches
Mail list logo
