Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Joe Perches]

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.
> > 
> > This now avoids any possible printk interleaving.
> > 
> > Unfortunately, without some #ifdef in vsprintf, which
> > I would like to avoid, it increases the nommu kernel
> > size by ~500 bytes.
> > 
> > Anyone think this is acceptable?
[]
> This doesn't feel like a huge win since it's only called ~once per
> architecture.  I'd be more excited if it made the printing of the whole
> thing standardised; eg we have a print_fault() function in mm/memory.c
> which takes a suitable set of arguments.

Sure but perhaps that's not feasible as the surrounding output
is per-arch specific.

What could be a standardized fault message here?

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Joe Perches]

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
print_vma_addr and removes all the uses similar to the
print_symbol() removal.

This now avoids any possible printk interleaving.

Unfortunately, without some #ifdef in vsprintf, which
I would like to avoid, it increases the nommu kernel
size by ~500 bytes.

Anyone think this is acceptable?

Here's the overall patch, but I have it as a series
---
 Documentation/core-api/printk-formats.rst |  9 +
 arch/arm64/kernel/traps.c | 13 +++
 arch/mips/mm/fault.c  | 16 -
 arch/parisc/mm/fault.c| 15 
 arch/riscv/kernel/traps.c | 11 +++---
 arch/s390/mm/fault.c  |  7 ++--
 arch/sparc/mm/fault_32.c  |  8 ++---
 arch/sparc/mm/fault_64.c  |  8 ++---
 arch/tile/kernel/signal.c |  9 ++---
 arch/um/kernel/trap.c | 13 +++
 arch/x86/kernel/signal.c  | 10 ++
 arch/x86/kernel/traps.c   | 18 --
 arch/x86/mm/fault.c   | 12 +++
 include/linux/mm.h|  1 -
 lib/vsprintf.c| 58 ++-
 mm/memory.c   | 33 --
 16 files changed, 112 insertions(+), 129 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 934559b3c130..10a91da1bc83 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -157,6 +157,15 @@ DMA address types dma_addr_t
 For printing a dma_addr_t type which can vary based on build options,
 regardless of the width of the CPU data path.
 
+VMA name and address
+
+
+::
+
+   %pav[hexstart+hexsize] or ?[0+0] if unavailable
+
+For any address, print the vma's name and its starting address and size
+
 Passed by reference.
 
 Raw buffer as an escaped string
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 2b478565d774..48edf812ce8b 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -242,13 +242,14 @@ void arm64_force_sig_info(struct siginfo *info, const 
char *str,
if (!show_unhandled_signals_ratelimited())
goto send_sig;
 
-   pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
if (esr)
-   pr_cont("%s, ESR 0x%08x, ", esr_get_class_string(esr), esr);
-
-   pr_cont("%s", str);
-   print_vma_addr(KERN_CONT " in ", regs->pc);
-   pr_cont("\n");
+   pr_info("%s[%d]: unhandled exception: %s, ESR 0x%08x, %s in 
%pav\n",
+   tsk->comm, task_pid_nr(tsk),
+   esr_get_class_string(esr), esr,
+   str, >pc);
+   else
+   pr_info("%s[%d]: unhandled exception: %s in %pav\n",
+   tsk->comm, task_pid_nr(tsk), str, >pc);
__show_regs(regs);
 
 send_sig:
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 4f8f5bf46977..ce7bf077a0f5 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -213,14 +213,14 @@ static void __kprobes __do_page_fault(struct pt_regs 
*regs, unsigned long write,
tsk->comm,
write ? "write access to" : "read access from",
field, address);
-   pr_info("epc = %0*lx in", field,
-   (unsigned long) regs->cp0_epc);
-   print_vma_addr(KERN_CONT " ", regs->cp0_epc);
-   pr_cont("\n");
-   pr_info("ra  = %0*lx in", field,
-   (unsigned long) regs->regs[31]);
-   print_vma_addr(KERN_CONT " ", regs->regs[31]);
-   pr_cont("\n");
+   pr_info("epc = %0*lx in %pav\n",
+   field,
+   (unsigned long)regs->cp0_epc,
+   >cp0_epc);
+   pr_info("ra  = %0*lx in %pav\n",
+   field,
+   (unsigned long)regs->regs[31],
+   >regs[31]);
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index e247edbca68e..877cea702714 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -240,17 +240,14 @@ show_signal_msg(struct pt_regs *regs, unsigned long 

Re: [PATCH 1/2] checkpatch: add check for tag Co-Developed-by

[Joe Perches]

On Mon, 2018-03-05 at 14:58 +1100, Tobin C. Harding wrote:
> From: Joe Perches <j...@perches.com>

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 know
> about it yet. All prior tags used all lowercase characters except for first
> character. Checks for this format had to be re-worked to allow for the
> new tag.
> 
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Tobin C. Harding <m...@tobin.cc>
> ---
>  scripts/checkpatch.pl | 58 
> +++
>  1 file changed, 35 insertions(+), 23 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3d4040322ae1..fbe2ae2d035f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -461,16 +461,18 @@ our $logFunctions = qr{(?x:
>   seq_vprintf|seq_printf|seq_puts
>  )};
>  
> -our $signature_tags = qr{(?xi:
> - Signed-off-by:|
> - Acked-by:|
> - Tested-by:|
> - Reviewed-by:|
> - Reported-by:|
> - Suggested-by:|
> - To:|
> - Cc:
> -)};
> +our @valid_signatures = (
> + "Signed-off-by:",
> + "Acked-by:",
> + "Tested-by:",
> + "Reviewed-by:",
> + "Reported-by:",
> + "Suggested-by:",
> + "Co-Developed-by:",
> + "To:",
> + "Cc:"
> +);
> +my $signature_tags = "(?x:" . join('|', @valid_signatures) . ")";
>  
>  our @typeListMisordered = (
>   qr{char\s+(?:un)?signed},
> @@ -2193,6 +2195,17 @@ sub pos_last_openparen {
>   return length(expand_tabs(substr($line, 0, $last_openparen))) + 1;
>  }
>  
> +sub get_preferred_sign_off {
> + my ($sign_off) = @_;
> +
> + foreach my $sig (@valid_signatures) {
> + if (lc($sign_off) eq lc($sig)) {
> + return $sig;
> + }
> + }
> + return "";
> +}
> +
>  sub process {
>   my $filename = shift;
>  
> @@ -2499,35 +2512,34 @@ sub process {
>   my $sign_off = $2;
>   my $space_after = $3;
>   my $email = $4;
> - my $ucfirst_sign_off = ucfirst(lc($sign_off));
> + my $preferred_sign_off = ucfirst(lc($sign_off));
>  
> - if ($sign_off !~ /$signature_tags/) {
> + if ($sign_off !~ /$signature_tags/i) {
>   WARN("BAD_SIGN_OFF",
>"Non-standard signature: $sign_off\n" . 
> $herecurr);
> - }
> - if (defined $space_before && $space_before ne "") {
> + } elsif ($sign_off !~ /$signature_tags/) {
> + $preferred_sign_off = 
> get_preferred_sign_off($sign_off);
>   if (WARN("BAD_SIGN_OFF",
> -  "Do not use whitespace before 
> $ucfirst_sign_off\n" . $herecurr) &&
> +  "'$preferred_sign_off' is the 
> preferred signature form\n" . $herecurr) &&
>   $fix) {
> - $fixed[$fixlinenr] =
> - "$ucfirst_sign_off $email";
> + $fixed[$fixlinenr] = 
> "$preferred_sign_off $email";
>   }
>   }
> - if ($sign_off =~ /-by:$/i && $sign_off ne 
> $ucfirst_sign_off) {
> + if (defined $space_before && $space_before ne "") {
>   if (WARN("BAD_SIGN_OFF",
> -  "'$ucfirst_sign_off' is the preferred 
> signature form\n" . $herecurr) &&
> +  "Do not use whitespace before 
> $preferred_sign_off\n" . $herecurr) &&
>   $fix) {
>   $fixed[$fixlinenr] =
> - "$ucfirst_sign_off $email";
> + "$preferred_sign_off $email";
>   }
> -
>   }
> +
> 

Re: [PATCH] doc: process: Add "Root-caused-by" and "Suggested-by"

[Joe Perches]

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 <j...@perches.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: process: Add "Root-caused-by" and "Suggested-by"

[Joe Perches]

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. Additionally updates checkpatch.pl to match the process docs.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -464,9 +464,11 @@ our $logFunctions = qr{(?x:
>  our $signature_tags = qr{(?xi:
>   Signed-off-by:|
>   Acked-by:|
> + Co-Developed-by:|
>   Tested-by:|
>   Reviewed-by:|
>   Reported-by:|
> + Root-caused-by:|
>   Suggested-by:|
>   To:|
>   Cc:

Patch does not match commit description
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Staging: netlogic: platform_net: Fixed '(' at the EOL

[Joe Perches]

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
> in having e.g. checkpatch.pl STFU, all wanking about uniformity
> of style nonwithstanding.

[ long and complete response removed, available at
  https://patchwork.kernel.org/patch/10162725/ ]

It was very generous of you to spend so much time on that
informative and thorough reply Al.

My own response was _much_ more terse.

What I wonder is if that sort of guided response can be
setup as documentation for kernel-newbies / janitors so
that future new submitters can have better ideas as to
what code can and should be improved instead of getting
simple and sometimes ill-advised whitespace changes.

cheers, Joe

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/3] doc: update printk documentation

[Joe Perches]

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 dangling reference to printk-formats.txt in lib/vsprintf.c
>that we'll want to fix up.

patch 1/3 updates that reference.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Joe Perches]

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 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/)
> 
> How many of these do you think it is worth to fix?
> 
> We do get a steady trickle of changes in this topic every cycle.
> 
> Is it better to just do a big number of them all at once?

I think so.

> Do you have
> an idea how disruptive this kind of work is to the whole patch flow
> eg new patches no longer applying to for-next, backports no longer
> applying, merge conflicts?

Some do complain about backport patch purity.

I think that difficulty is overstated, but then
again, I don't do backports very often.

I think the best time for any rather wholesale
change is immediately after an rc-1 so overall
in-flight patch conflict volume is minimized.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Joe Perches]

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/)
> 
> Yes, and I already did that work piece by piece for individual types,
> just to test the runchecks tool, and want to post that set once the 
> runchecks script and Makefile changes itself are in,

I think those are independent of any runcheck tool changes and
could be posted now.  In general, don't keep patches in a local
tree waiting on some other unrelated patch.

Just fyi:

There is a script that helps automate checkpatch "by-type" conversions
with compilation, .o difference checking, and git commit editing.

https://lkml.org/lkml/2014/7/11/794

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Joe Perches]

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 subsystems should be treated equally.
> > 
> > This is a tool to enable automated testing for as many checks as
> > possible, as soon as possible. Like any tool, it can be misused, but
> > that's IMHO an orthogonal problem that I think the maintainers will
> > be more than capable of preventing.
> > 
> > Think of this as a tightening screw: We eliminate errors class by
> > class or file by file, and in the same commit narrows in the list of
> > exceptions. That way we can fix issues piece by piece while avoiding
> > a lot of regressions in already clean parts.
> 
> Since you used drivers/infiniband as an example for this script..
> 
> I will say I agree with this idea.
> 
> It is not that we *want* infiniband to be different from the rest of
> the kernel, it is that we have this historical situation where we
> don't have a code base that already passes the various static checker
> things.
> 
> I would like it very much if I could run 'make static checker' and see
> no warnings. This helps me know that I when I accept patches I am not
> introducing new problems to code that has already been cleaned up.
> 
> 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 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/)

   5243 CHECK:CAMELCASE
   4487 WARNING:LONG_LINE
   1755 CHECK:PARENTHESIS_ALIGNMENT
   1664 CHECK:SPACING
910 WARNING:FUNCTION_ARGUMENTS
742 CHECK:OPEN_ENDED_LINE
685 CHECK:BRACES
643 CHECK:UNNECESSARY_PARENTHESES
478 WARNING:SIZEOF_PARENTHESIS
361 WARNING:UNSPECIFIED_INT
342 WARNING:LONG_LINE_COMMENT
338 ERROR:SPACING
338 CHECK:LINE_SPACING
306 WARNING:SPLIT_STRING
278 WARNING:SPACING
242 WARNING:SYMBOLIC_PERMS
194 WARNING:BLOCK_COMMENT_STYLE
175 CHECK:BIT_MACRO
158 WARNING:SPACE_BEFORE_TAB
154 WARNING:LINE_SPACING
139 CHECK:MACRO_ARG_REUSE
133 CHECK:UNCOMMENTED_DEFINITION
122 CHECK:AVOID_BUG
103 CHECK:COMPARISON_TO_NULL
101 WARNING:ENOSYS
 89 WARNING:BRACES
 78 WARNING:PREFER_PR_LEVEL
 74 WARNING:MULTILINE_DEREFERENCE
 59 CHECK:TYPO_SPELLING
 52 WARNING:EMBEDDED_FUNCTION_NAME
 52 CHECK:MULTIPLE_ASSIGNMENTS
 50 CHECK:PREFER_KERNEL_TYPES
 45 WARNING:RETURN_VOID
 39 WARNING:UNNECESSARY_ELSE
 38 ERROR:POINTER_LOCATION
 37 WARNING:ALLOC_WITH_MULTIPLY
 36 CHECK:ALLOC_SIZEOF_STRUCT
 35 CHECK:AVOID_EXTERNS
 34 WARNING:PRINTK_WITHOUT_KERN_LEVEL
 33 ERROR:CODE_INDENT
 32 WARNING:PREFER_PACKED
 32 CHECK:LOGICAL_CONTINUATIONS
 29 WARNING:MEMORY_BARRIER
 29 WARNING:LEADING_SPACE
 28 WARNING:DEEP_INDENTATION
 27 CHECK:USLEEP_RANGE
 23 WARNING:SUSPECT_CODE_INDENT
 23 ERROR:TRAILING_STATEMENTS
 21 WARNING:LONG_LINE_STRING
 20 WARNING:CONSIDER_KSTRTO
 18 WARNING:CONSTANT_COMPARISON
 18 ERROR:OPEN_BRACE
 15 WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE
 14 WARNING:VOLATILE
 14 ERROR:SWITCH_CASE_INDENT_LEVEL
 11 WARNING:OOM_MESSAGE
 11 WARNING:INCLUDE_LINUX
 10 WARNING:SSCANF_TO_KSTRTO
 10 WARNING:INDENTED_LABEL
  9 ERROR:GLOBAL_INITIALISERS
  9 ERROR:COMPLEX_MACRO
  9 ERROR:ASSIGN_IN_IF
  8 WARNING:UNNECESSARY_BREAK
  6 WARNING:PRINTF_L
  6 WARNING:MISORDERED_TYPE
  6 ERROR:INITIALISED_STATIC
  5 WARNING:TABSTOP
  5 WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO
  5 WARNING:NAKED_SSCANF
  4 WARNING:NEEDLESS_IF
  4 ERROR:RETURN_PARENTHESES
  4 CHECK:BOOL_COMPARISON
  3 WARNING:TRAILING_SEMICOLON
  3 WARNING:STATIC_CONST_CHAR_ARRAY
  3 ERROR:TRAILING_WHITESPACE
  2 WARNING:UNNECESSARY_PARENTHESES
  2 WARNING:MISSING_SPACE
  2 WARNING:LOGGING_CONTINUATION
  2 CHECK:ARCH_DEFINES
  1 WARNING:TYPECAST_INT_CONSTANT
  1 WARNING:PREFER_DEV_LEVEL
  1 WARNING:NR_CPUS
  1 WARNING:NEW_TYPEDEFS
  1 WARNING:MINMAX
  1 WARNING:MACRO_WITH_FLOW_CONTROL
  1 WARNING:LINE_CONTINUATIONS
  1 WARNING:DO_WHILE_MACRO_WITH_TRAILING_SEMICOLON
  1 WARNING:DEFAULT_NO_BREAK
  1 WARNING:CONST_STRUCT
  1 WARNING:CONSIDER_COMPLETION
  1 ERROR:WHILE_AFTER_BRACE
  1 ERROR:ELSE_AFTER_BRACE
  1 CHECK:REDUNDANT_CODE

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] doc: update printk documentation

[Joe Perches]

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-formats.txt when making changes **

> I'd like to get it _realy_ correct so that future

sp: realy->really

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Joe Perches]

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 replacing the sparse specific setup for the C={1,2} variable
> > in the makefiles with setup for running scripts/runchecks, a new program 
> > that
> > can run any number of different "checkers". The behaviour of runchecks is
> > defined by simple "global" configuration in scripts/runchecks.cfg which can 
> > be
> > extended by local configuration applying to individual files, directories or
> > subtrees in the source.
[]
> 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 subsystems should be treated equally.
> 
> There was discussion at Kernel Summit about how the different
> subsystems already have different rules. This appears to be a
> way to make that worse.

I think that's OK and somewhat reasonable.

What is perhaps unreasonable is requiring subsystems with
a local specific style to change to some universal style.

see comments like:

https://lkml.org/lkml/2017/12/11/689
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Joe Perches]

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
> > > entire kernel as part of automatic and developer testing.
> > 
> > This seems like a useful and reasonable series, thanks.
> 
> thanks, appreciated,
> 
> > Do please take Julia's grammar updates.
> 
> will do,
> 
> > How is this series to be applied?
> 
> I am open for suggestions.
> 
> Let's leave patch #3 out for now.
> 
> It's safe to apply #1 (and #2) alone.

I'd just as soon combine patch #1 and an updated 
patch #2 into a single patch and get that applied
sooner than later.

> They don't break anything by getting into the RDMA or RDS subsystem 
> without patch #1, alternatively they can go together with the set of cleanup 
> patches I
> have prepared for each of RDMA and RDS after #1 is in.

right.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Joe Perches]

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 this series to be applied?

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Joe Perches]

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 passed as an argument.
> 
> This sounds interesting to work no. At first glance I have no idea how
> one would go about this. Some form of static analysis would be a good
> place to start, right? I'd like to allocate some cycles to this, any
> pointers most appreciated.

A gcc-plugin would likely work best.

There was some discussion about such a thing here:
http://www.openwall.com/lists/kernel-hardening/2017/02/14/38

I vaguely recall someone else doing a broader use tool
which I believe was not smatch, but my google-fu isn't
finding it.

It might have been coccinelle based.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Joe Perches]

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 fine, but it shouldn't reduce the detail that is
> present, IMO. Now, expanding on it in printk-formats.rst is certainly
> a great idea, but I don't think it should come at the expense of
> someone just reading through vsprintf.c. That said, I can certainly
> see that redundancy is annoying, and it's possible for
> printk-formats.rst and vsprintf.c get get out of sync, but that
> doesn't seem to be a new problem.

Nor has it been a real problem in practice.

There is a comment in vsprintf.c that tells people
to update the doc.

 * ** Please update also Documentation/printk-formats.txt when making changes **
> 
> I'd be curious to see what Jon or Joe think about this.
> 
> (Perhaps the best first step would be to leave vsprintf.c as-is
> without kernel-doc-ification?)

I think adding kernel-doc to vsprintf.c is unnecessary.

Outside of the documentation, what could be useful is for
someone to add a tool to verify %p extension to
the typeof address actually passed as an argument.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Joe Perches]

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 currently .txt
[]
> just a question .. might it be better we stay with ASCII table
> in cases like this. I guess this table won't changed often.
> The flat-table directive is good for big and therefore frequently 
> changed tables where a small precise diff reduce the patch.
> But flat-table is also hard to read in plain text. Its a balancing
> and thats my opinion, lets hear what other say ...

I think the proposed conversion is unreadable
and the original table quite clear.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

[Joe Perches]

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 messages
> > > for this software transformation pattern?
> > 
> > Add a description of _why_ this is being done.
> > 
> > Something like:
> > 
> > "because there is a dump_stack() done on allocation failures
> >  without __GFP_JNOWARN"
> 
> How do you think about to convert such a description into a special format
> for further reference documentation?

I think it's a bad idea if it's a "special" format.

Always write _why_ some code is being changed.

People could read the commit descriptions and would not need
to take extra time to lookup external references.

Maybe add something like
"see (commit  or )" for additional details"

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] move visorbus out of staging to drivers/virt/visorbus

[Joe Perches]

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 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 callbacks in that file seem to all have
> > > their leading '{' in the wrong place.  Odd that checkpatch.pl doesn't
> > > catch that...
[]
> the following code in that file should be caught, right:
> 
> static ssize_t partition_handle_show(struct device *dev,
>  struct device_attribute *attr,
>  char *buf) {
> struct visor_device *vdev = to_visor_device(dev);
> u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
> 
> return sprintf(buf, "0x%llx\n", handle);
> }
> static DEVICE_ATTR_RO(partition_handle);

Not really.

> The initial { is in the wrong place...

True.

Please understand that checkpatch looks at patches one line
at a time.  It's not very smart about function definitions
or context.

checkpatch's function definition code is pretty limited.
It can miss a lot of style misuses.

Single line function definitions brace tests work well.
Multiple line function definitions do not.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] move visorbus out of staging to drivers/virt/visorbus

[Joe Perches]

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 callbacks in that file seem to all have
> their leading '{' in the wrong place.  Odd that checkpatch.pl doesn't
> catch that...

checkpatch doesn't really check much about inconsistent
indentation.  I believe the only new statement indentation
check is after an if.

For instance, checkpatch doesn't emit a warning on this code:

struct foo {
int bar;
};

struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
if (baz)
baz->bar = 1;
return baz;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/29] printk-formats.txt: standardize document format

[Joe Perches]

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 for the document;
> - add markups for section titles;
> - move authorship to the beginning and use :Author:;
> - use right markup for tables;
> - mark literals and literal blocks.

I think the .rst markup is far uglier to read as text
and harder to modify for new additions to %p
given column alignments.

For instance below, but other than that, the .rst
is easier to read.

> diff --git a/Documentation/printk-formats.txt 
> b/Documentation/printk-formats.txt
[]
> @@ -1,139 +1,180 @@
> -If variable is of Type,  use printk format specifier:
> --
> - int %d or %x
> - unsigned int%u or %x
> - long%ld or %lx
> - unsigned long   %lu or %lx
> - long long   %lld or %llx
> - unsigned long long  %llu or %llx
> - size_t  %zu or %zx
> - ssize_t %zd or %zx
> - s32 %d or %x
> - u32 %u or %x
> - s64 %lld or %llx
> - u64 %llu or %llx
[]
> +=== ===
> +If variable is of Type   use printk format specifier
> +=== ===
> +``int``  ``%d or %x``
> +``unsigned int`` ``%u or %x``
> +``long`` ``%ld or %lx``
> +``unsigned long````%lu or %lx``
> +``long long````%lld or %llx``
> +``unsigned long long``   ``%llu or %llx``
> +``size_t``   ``%zu or %zx``
> +``ssize_t``  ``%zd or %zx``
> +``s32``  ``%d or %x``
> +``u32``  ``%u or %x``
> +``s64``  ``%lld or %llx``
> +``u64``  ``%llu or %llx``
> +=== ===


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Joe Perches]

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(_chip->dev);
> > > > > + if (ret < 0)
> > > > > + dev_err(_chip->dev,
> > > > > + "device_add failed in mux_chip_register: %d\n", 
> > > > > ret);
> > > > 
> > > > Did you run checkpatch.pl in strict mode on this new file?  Please do 
> > > > so :)
> > > 
> > > I did, and did it again just to be sure, and I do not get any complaints.
> > > So, what's wrong?
> > 
> > You list the function name in the printk string, it should complain
> > that __func__ should be used.  Oh well, it's just a perl script, it
> > doesn't always catch everything.
> > isn't always correct :)
> 
> Ah, ok.

Also, please use the checkpatch in -next as it has a
slightly better mechanism to identify functions and
uses in strings.

$ ./scripts/checkpatch.pl ~/1.patch
WARNING: Prefer using '"%s...", __func__' to using 'mux_chip_register', this 
function's name, in a string
#302: FILE: drivers/mux/mux-core.c:134:
+   "device_add failed in mux_chip_register: %d\n", ret);


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Joe Perches]

(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, teaching people that the
> > file got renamed and were it is located now. As such, we can remove
> > those "pointer files" on some future Kernel releases without much concern.
> > 
> > A symlink indicates a more permanent situation, as people will keep
> > using the symlinked files as before. That means that any attempt to
> > remove those in the future will generate concerns.
> > 
> > So, I'm in favor of using the "pointer files" instead, as it
> > gives us an easier way to get rid of them when we find convenient.
> 
> So you've all long since forgotten this discussion, I'm sure, but I've
> been pondering it on and off for quite a while.
> 
> The movement of some of the more well-known documents has been a concern
> of mine from the beginning; that is why I delayed those changes for
> a cycle and raised the issue at a number of conferences, culminating in
> the kernel summit in November.  I got a strong sense of consensus that we
> should go ahead and move the files.
> 
> As Mauro says, symlinks are forever; they say we'll never really succeed
> in rationalizing the structure of Documentation/.  But we don't nail down
> the location of any other files in the kernel source tree in this manner,
> and my own feeling is that we shouldn't do that here either.  The kernel
> source tree is not an API.  So my thinking at the moment is that we should
> retain the current "pointer files" in the vague hope that, someday, we
> won't need them anymore.

I'm still of the opposite opinion.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Joe Perches]

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 without given consideration.

Yup.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Joe Perches]

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
> @@
> identifier fn;
> type T;
> @@
> 
> T fn ( ..., struct device * dev, ... ) {
> <...
> - pr_emerg(
> + dev_emerg(dev,
>   ...);
> ...>
> }

Well, the second question is simple if I would just
think a little before asking...

@@
identifier fn;
identifier dev;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

etc...

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn

[Joe Perches]

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 blocks
  one for each replacement
o can struct device * dev be made an arbitrary identifier

$ cat dev_printk.cocci
@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_emerg(
+   dev_emerg(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_crit(
+   dev_crit(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_alert(
+   dev_alert(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_err(
+   dev_err(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_notice(
+   dev_notice(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_warn(
+   dev_warn(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_info(
+   dev_info(dev,
...);
...>
}

@@
identifier fn;
type T;
@@

T fn ( ..., struct device * dev, ... ) {
<...
-   pr_debug(
+   dev_dbg(dev,
...);
...>
}

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Joe Perches]

On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
> On Tue, 10 Jan 2017 14:09:51 -0800
> Joe Perches <j...@perches.com> 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: why do we need to make that change?  Have the
> existing one-liner files been a problem somehow?

The files tell people to open other files.

Giving the old link to people just tells them to
use the new filename instead.

symlinks open the new file automatically.

$ head Documentation/CodingStyle
This file has moved to process/coding-style.rst

vs a symlink

$ head Documentation/CodingStyle
.. _codingstyle:

Linux kernel coding style
=

This is a short document describing the preferred coding style for the
linux kernel.  Coding style is very personal, and I won't **force** my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too.  Please
at least consider the points made here.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Joe Perches]

On Wed, 2017-01-11 at 10:54 +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2017, Joe Perches <j...@perches.com> 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: 08a9a8d44c1c ("doc: re-add CodingStyle and SubmittingPatches")

I don't believe this patch "fixes" the other, it just makes it
possible to continue to write "Read Documentation/CodingStyle"
or "Read Documentation/SubmittingPatches" to people that
submit poorly formatted or improper patches.

I attempted to do that a bit ago but then had to write out the
Documentation/process/.rst equivalents instead.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Joe Perches]

Make these files symlinks to the .rst equivalents

Signed-off-by: Joe Perches <j...@perches.com>
---
 Documentation/CodingStyle   | 2 +-
 Documentation/SubmittingPatches | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 mode change 100644 => 12 Documentation/CodingStyle
 mode change 100644 => 12 Documentation/SubmittingPatches

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
deleted file mode 100644
index 320983ca114e..
--- a/Documentation/CodingStyle
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to process/coding-style.rst
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
new file mode 12
index ..5aacf7ea935a
--- /dev/null
+++ b/Documentation/CodingStyle
@@ -0,0 +1 @@
+./process/coding-style.rst
\ No newline at end of file
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
deleted file mode 100644
index 81455705e4a6..
--- a/Documentation/SubmittingPatches
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to process/submitting-patches.rst
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 12
index ..5ca6e8ba3682
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1 @@
+./process/submitting-patches.rst
\ No newline at end of file
-- 
2.10.0.rc2.1.g053435c

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 07/10] kmod: use simplified rate limit printk

[Joe Perches]

On Wed, 2016-12-14 at 17:23 +0100, Petr Mladek wrote:
> On Thu 2016-12-08 11:49:01, Luis R. Rodriguez wrote:
> > Just use the simplified rate limit printk when the max modprobe
> > limit is reached, while at it throw out a bone should the error
> > be triggered.
[]
> > diff --git a/kernel/kmod.c b/kernel/kmod.c
[]
> > @@ -183,13 +182,8 @@ int __request_module(bool wait, const char *fmt, ...)
> >  
> > ret = kmod_umh_threads_get();
> > if (ret) {
> > -   /* We may be blaming an innocent here, but unlikely */
> > -   if (kmod_loop_msg < 5) {
> > -   printk(KERN_ERR
> > -  "request_module: runaway loop modprobe %s\n",
> > -  module_name);
> > -   kmod_loop_msg++;
> > -   }
> > +   pr_err_ratelimited("request_module: modprobe limit (%u) reached 
> > with module %s\n",
> > +  max_modprobes, module_name);
> 
> I like this change. I would only be even more descriptive in which
> limit is reached. Something like
> 
>   pr_err_ratelimited("request_module: module \"%s\" reached limit 
> (%u) of concurrent modprobe calls\n",
>  module_name, max_modprobes);
> 
> Either way, feel free to add:
> 
> Reviewed-by: Petr Mladek 

Seems sensible.

I suggest using "%s: ", __func__ instead of embedding
the function name.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: add note on usleep_range range

[Joe Perches]

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 Tue, 13 Dec 2016, Nicholas Mc Guire <hof...@osadl.org> wrote:
> > > > > useleep_range() with a delta of 0 makes no sense and only prevents the
> > > > > timer subsystem from optimizing interrupts. As any user of 
> > > > > usleep_range()
> > > > > is in non-atomic context the timer jitter is in the range of 10s of 
> > > > > microseconds anyway.
> > > > > 
> > > > > This adds a note making it clear that a range of 0 is a bad idea.
> > > > 
> > > > So I don't really have anything to do with the timer subsystem, I'm just
> > > > their "consumer", so take this with a grain of salt.
> > > > 
> > > > Documentation is good, but I don't think this will be enough.
> > > > 
> > > > I think the only thing that will work is to detect and complain about
> > > > things like this automatically. Some ideas:
> > > > 
> > > > * WARN_ON(min == max) or WARN_ON_ONCE(min == max) in usleep_range()
> > > >   might be drastic, but it would get the job done eventually.
> > > > 
> > > > * If you want to avoid the runtime overhead (and complaints about the
> > > >   backtraces), you could wrap usleep_range() in a macro that does
> > > >   BUILD_BUG_ON(min == max) if the parameters are build time constants
> > > >   (they usually are). But you'd have to fix all the problem cases first.
> > > > 
> > > > * You could try (to persuade Julia or Dan) to come up with a
> > > >   cocci/smatch check for usleep_range() calls where min == max, so we
> > > >   could get bug reports for this. This probably works on expressions, so
> > > >   this would catch also cases where the parameters aren't built timea,
> > > >   constants.
> > 
> > You could also add a macro for usleep_range like
> > 
> > #define usleep_range(a, b) \
> > ({ \
> > if (__builtin_constant_p(a) && __builtin_constant_p(b)) { \
> > if (a == b) \
> > __compiletime_warning("Better to use usleep_range with 
> > different values"); \
> > else if (a > b) \
> > __compiletime_error("usleep_range uses smaller value 
> > first"); \
> > } \
> > usleep_range(a, b); \
> > })
> > 
> 
> thanks for that "template" 
>  
> > and add parentheses around the actual function
> > definition for usleep_range in kernel/time/timer.c
> > so the macro works and these messages get emitted
> > at compile-time.
> > 
> 
> while compiletime warnings are a way to go I think that an
> external tool is more effective than anoying eveyone during
> build

I don't.

Annoying people at build-time is probably _the single most_
effective way to get source code defects fixed.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] printk: introduce kptr_restrict level 3

[Joe Perches]

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 default
and using NULL for data pointers.

https://lkml.org/lkml/2016/8/5/380

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

[Joe Perches]

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
> contents of the maintainers entries.
> 
> There's a side effect of this approach: now, if the
> explanation text at the MAINTAINERS file is touched, it should be
> modified also at the Documentation/user/MAINTAINERS.rst file.
> Yet, as the number of changes there are small, this
> should be manageable.

couldn't this be a generated file from some awk script instead
of being duplicated content with a plea to be kept in sync?

> diff --git a/Documentation/user/MAINTAINERS.rst 
> b/Documentation/user/MAINTAINERS.rst
> new file mode 100644

[etc]

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

[Joe Perches]

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 that related?) and now you pull statistics
> out of your hat, like these numbers imply anything.

No, not out of a hat.  Those are the results of a silly script that
runs checkpatch on every .[ch] kernel file (but not tools/) with:

--show-types --terse --emacs --strict --no-summary --quiet -f

The magnitude of "ERRORS" is high and it's not necessary or useful
to modify old or obsolete code just to reduce that magnitude.

> checkpatch was called checkPATCH for a reason.

That's why I promote the --force option to limit using checkpatch on
files outside of staging.

https://patchwork.kernel.org/patch/9332205/

Andrew?  Are you going to apply that one day?

> ERROR means that the new code isn't allowed to do that. Period.

Disagree.  The compiler doesn't care.  The value of consistency in
reducing defects is very hard to quantify.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

[Joe Perches]

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 anyone is getting paid per commit.
Who really cares enough to game some stupid little metric?

If it's really a big deal, name some names.  Otherwise please
stop with this dubious argument/point.

> Some of these checks are common-sense, some are
> absolutely arbitrary,

Essentially all of the checkpatch rules are arbitrary.
The compiler doesn't care one way or another.

All the checks exist just to make code appear more consistent.

The conceit being that more consistent code is easier for humans
to read and spot potential defects and possible reuse patterns.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

[Joe Perches]

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 won't run the script by themselves, instead they will
>   submit a patch which infringes a lot of coding style rules, and the
>   maintainer will point them to checkpatch and ask for a resubmission
>   which makes checkpatch happy. Being beginners, they can only rely on
>   the script itself to only report things which need to be fixed, by
>   default.
> * Experienced developers. Who simply want to make sure they did not
>   overlook anything before they post their work for review. They have
>   the knowledge to decide if they want to ignore some of the warnings.
> * People with too much spare time, looking for anything they could
>   "contribute" to the kernel. They will use --subjective and piss off
>   every maintainer they can find.

I think you overlook the category of a beginner submitting
"my first kernel patch" which is a "coding style" defect of
some type.  The Eudyptula and Outreachy programs seem to
encourage these sorts of patches.

This is where "scripts/checkpatch.pl -f " is most used.

I believe adding the --force option might be useful to
restrict cleanup-style-only patches outside of staging.

There's nothing wrong with cleanup style patches, it can be
good introduction to compiler/config tool & kernel setup.
 
> I would rather suggest:
> 
> ERROR -> MUST_FIX
> WARNING -> SHOULD_FIX
> CHECK -> MAY_FIX

MUST is much stronger language than I would prefer.

There are still about a quarter million ERRORs just for
spacing issues in the kernel tree.

Here are the top 10 ERROR checkpatch messages treewide as of
a few days ago,

$ grep ERROR checkpatch.short_sorted_20160917
 268308  ERROR:SPACING
  37340  ERROR:CODE_INDENT
  27678  ERROR:TRAILING_WHITESPACE
  21024  ERROR:COMPLEX_MACRO
  14048  ERROR:POINTER_LOCATION
  12207  ERROR:TRAILING_STATEMENTS
  11079  ERROR:OPEN_BRACE
   6802  ERROR:ASSIGN_IN_IF
   3940  ERROR:RETURN_PARENTHESES
   2322  ERROR:NON_OCTAL_PERMISSIONS

Maybe there could be some better classifications of the various
messages.

But there are about two million checkpatch messages overall in
the kernel tree.

That's a lot.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Remove space-before-label guidance from CodingStyle

[Joe Perches]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

[Joe Perches]

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 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 think that checkpatch's ERROR/WARNING/CHECK message naming is
> > far too severe and injunctive and could use a renaming to something
> > more silly, bug related and less commanding like FLEAS/GNATS/NITS.
> I think it is better to be clear.  CHECK was never really clear to me,
> especially if you see it in isolation, on a file that doesn't also have
> ERROR or WARNING.  NITS is a common word in this context, but not FLEAS
> and GNATS, as far as I know.
> There could also be a severity level: high medium and low

I agree clarity is good.

The seriousness with which some beginners take these message
types though is troublesome,

Maybe prefix various different types of style messages.

Something like:

ERROR   -> CODE_STYLE_DEFECT
WARNING -> CODE_STYLE_UNPREFERRED
CHECK   -> CODE_STYLE_NIT

I doubt additional external documentation would help much.

Some checkpatch bleats really are errors though.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

[Joe Perches]

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 think that checkpatch's ERROR/WARNING/CHECK message naming is
far too severe and injunctive and could use a renaming to something
more silly, bug related and less commanding like FLEAS/GNATS/NITS.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Updating MAINTAINERS and Documentation/video4linux F: patterns

[Joe Perches]

On Tue, 2016-09-13 at 12:22 +0300, Jani Nikula wrote:
> > On Sat, 10 Sep 2016, Joe Perches <j...@perches.com> wrote:
> After all the moving of video4linux Documentation file locations
> around and converting .txt files to .rst, can you please update
> the appropriate MAINTAINERS sections and F: patterns?
> 
> Hmm, for patches doing rename/create/delete, checkpatch could look at
> MAINTAINERS and remind the user if a MAINTAINERS update is needed.

Thanks, checkpatch already does exactly that.

$ ./scripts/checkpatch.pl -git 43efd1edc63534d3a7486a0548c8aedf8b1128d1
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#86: 
deleted file mode 100644

total: 0 errors, 1 warnings, 56 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Commit 43efd1edc635 ("[media] get rid of 
Documentation/video4linux/lifeview.txt") has style problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

or another way:

$ git log --stat -p  --format=email -1 -M 
43efd1edc63534d3a7486a0548c8aedf8b1128d1 | ./scripts/checkpatch.pl -
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#84: 
deleted file mode 100644

total: 0 errors, 1 warnings, 56 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/20] docs-rst: CodingStyle.rst: Convert to ReST markup

[Joe Perches]

On Mon, 2016-09-12 at 23:17 -0300, Mauro Carvalho Chehab wrote:
> - Fix all chapter identation;
> - add c blocks where needed;

Assuming this is really useful and people agree with simple
conversions of .txt to .rst (and it does have some use),
there are a couple funky conversions

if (condition)
do_this();
else
do_that();

do_that() is oddly displayed in the code_block

and in the "Spaces" section, the pointer description is wrong

"\* is adjacent"

other than that, looks good to me.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Updating MAINTAINERS and Documentation/video4linux F: patterns

[Joe Perches]

Hello Mauro.

After all the moving of video4linux Documentation file locations
around and converting .txt files to .rst, can you please update
the appropriate MAINTAINERS sections and F: patterns?

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

[Joe Perches]

On Tue, 2016-09-06 at 16:47 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > >         xfuncname = "^[[:alpha:]$_].*[^:]$"
> > OK, I see. As mentioned somewhere else, it fails for labels which have
> > comments. 
> Heh, There's labels that have comments?

Only a few dozen.

The pattern with the perl-like $_ took me a depressingly
long time to parse followed by a self forehead slap.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] treewide: Remove references to the now unnecessary DEFINE_PCI_DEVICE_TABLE

[Joe Perches]

It's been eliminated from the sources, remove it from everywhere else.

Signed-off-by: Joe Perches <j...@perches.com>
---
 Documentation/PCI/pci.txt | 1 -
 include/linux/pci.h   | 9 -
 scripts/checkpatch.pl | 9 -
 scripts/tags.sh   | 1 -
 4 files changed, 20 deletions(-)

diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt
index 123881f..77f49dc 100644
--- a/Documentation/PCI/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -124,7 +124,6 @@ initialization with a pointer to a structure describing the 
driver
 
 The ID table is an array of struct pci_device_id entries ending with an
 all-zero entry.  Definitions with static const are generally preferred.
-Use of the deprecated macro DEFINE_PCI_DEVICE_TABLE should be avoided.
 
 Each entry consists of:
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fbc1fa6..0ab8359 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -683,15 +683,6 @@ struct pci_driver {
 #defineto_pci_driver(drv) container_of(drv, struct pci_driver, driver)
 
 /**
- * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
- * @_table: device table name
- *
- * This macro is deprecated and should not be used in new code.
- */
-#define DEFINE_PCI_DEVICE_TABLE(_table) \
-   const struct pci_device_id _table[]
-
-/**
  * PCI_DEVICE - macro used to describe a specific pci device
  * @vend: the 16 bit PCI Vendor ID
  * @dev: the 16 bit PCI Device ID
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 8946904..1c82b01 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3610,15 +3610,6 @@ sub process {
}
}
 
-# check for uses of DEFINE_PCI_DEVICE_TABLE
-   if ($line =~ /\bDEFINE_PCI_DEVICE_TABLE\s*\(\s*(\w+)\s*\)\s*=/) 
{
-   if (WARN("DEFINE_PCI_DEVICE_TABLE",
-"Prefer struct pci_device_id over deprecated 
DEFINE_PCI_DEVICE_TABLE\n" . $herecurr) &&
-   $fix) {
-   $fixed[$fixlinenr] =~ 
s/\b(?:static\s+|)DEFINE_PCI_DEVICE_TABLE\s*\(\s*(\w+)\s*\)\s*=\s*/static const 
struct pci_device_id $1\[\] = /;
-   }
-   }
-
 # check for new typedefs, only function parameters and sparse annotations
 # make sense.
if ($line =~ /\btypedef\s/ &&
diff --git a/scripts/tags.sh b/scripts/tags.sh
index ed7eef2..b3775a9 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -206,7 +206,6 @@ regex_c=(
'/\<DEFINE_PER_CPU_SHARED_ALIGNED([^,]*, *\([[:alnum:]_]*\)/\1/v/'
'/\<DECLARE_WAIT_QUEUE_HEAD(\([[:alnum:]_]*\)/\1/v/'
'/\<DECLARE_\(TASKLET\|WORK\|DELAYED_WORK\)(\([[:alnum:]_]*\)/\2/v/'
-   '/\<DEFINE_PCI_DEVICE_TABLE(\([[:alnum:]_]*\)/\1/v/'
'/\(^\s\)OFFSET(\([[:alnum:]_]*\)/\2/v/'
'/\(^\s\)DEFINE(\([[:alnum:]_]*\)/\2/v/'
'/\<DEFINE_HASHTABLE(\([[:alnum:]_]*\)/\1/v/'
-- 
2.10.0.rc2.1.gb2aa91d

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus

[Joe Perches]

On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote:
> nr_cpus can help to save memory. So we should remind user of it.

trivia:
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
[]
> @@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel:
>  * Boot parameter "1" boots the dump-capture kernel into single-user
>    mode without networking. If you want networking, use "3".
>  
> -* We generally don' have to bring up a SMP kernel just to capture the
> +* We generally don' have to bring up an SMP kernel just to capture the

don't or do not

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] CodingStyle: Remove "Don't use C99-style comments"

[Joe Perches]

On Sun, 2016-08-14 at 12:09 -0700, Randy Dunlap wrote:

> I like it, but like Linus said, we don't want people to send
> patches just to "fix" the comment style.

Just fyi, checkpatch makes no recommendation about
converting single line comments to //.

And it shouldn't in my opinion.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] CodingStyle: Remove "Don't use C99-style comments"

[Joe Perches]

On Sun, 2016-08-14 at 12:35 -0600, Jonathan Corbet wrote:
> On Thu, 04 Aug 2016 10:55:14 -0700 Joe Perches <j...@perches.com> wrote:
> > > Because Linus may still be reading source code on greenbar paper
> > > instead of color terminals with code syntax highlighting and
> > > appropriate font decorations.
> > > 
> > > Link: 
> > > http://lkml.kernel.org/r/ca+55afyqyjerovmssosks7pesszbr4vnp-3quuwhqk4a4_j...@mail.gmail.com
[]
> > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
[]
> > > @@ -461,9 +461,6 @@ When commenting the kernel API functions, please use 
> > > the kernel-doc format.
> > >  See the files Documentation/kernel-doc-nano-HOWTO.txt and 
> > > scripts/kernel-doc
> > >  for details.
> > >  
> > > -Linux style for comments is the C89 "/* ... */" style.
> > > -Don't use C99-style "// ..." comments.
> > > -
> > >  The preferred style for long (multi-line) comments is:
> > >  
> > >   /*  
> > ping?
> Sorry, I've not been ignoring this, I've just not yet worked up the
> courage to apply it.  Yes, Linus said he's fine with C++-style comments,
> but I still expect some pushback when people start actually sending them.
> I don't quite feel a sense of community consensus on this one.
> 
> Still, what the heck, I'll go ahead and apply it.  We can always revert it
> when people start screaming :)

;)

Yeah, that was my thought too when I sent the patch for
checkpatch to ignore // comments.

What the heck.

I just don't care that much how people comment their code.

Syntax coloring and highlighting works in every editor I use
except the email client and I should change the one I use
(evolution) one day because it's broken anyway.

cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] Documentation: Move samples from doc to samples/

[Joe Perches]

On Mon, 2016-07-18 at 15:27 -0400, Mahesh Khanwalkar wrote:
> Moved sample code found in Documentation/ to samples/ but kept actual
> documentation where it is, while updating any in-text references to the
> moved code. Updated the Documentation/Makefile and samples/Makefile to
> reflect the change. Built with CONFIG_SAMPLES=y in .config with no
> build errors. The directories added within samples/ still follow the
> same structure that they did in Documentation. Directories in
> Documentation/ that contained code still exist, only the code within
> them has been moved out accordingly.

The MAINTAINERS file should also have file patterns updated.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] CodingStyle: Remove "Don't use C99-style comments"

[Joe Perches]

Because Linus may still be reading source code on greenbar paper
instead of color terminals with code syntax highlighting and
appropriate font decorations.

Link: 
http://lkml.kernel.org/r/ca+55afyqyjerovmssosks7pesszbr4vnp-3quuwhqk4a4_j...@mail.gmail.com

Signed-off-by: Joe Perches <j...@perches.com>
---
 Documentation/CodingStyle | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 9a70ddd..19b2e9c 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -461,9 +461,6 @@ When commenting the kernel API functions, please use the 
kernel-doc format.
 See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
 for details.
 
-Linux style for comments is the C89 "/* ... */" style.
-Don't use C99-style "// ..." comments.
-
 The preferred style for long (multi-line) comments is:
 
/*
-- 
2.8.0.rc4.16.g56331f8

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: fix "interruptible" misspellings

[Joe Perches]

On Thu, 2016-06-09 at 13:29 -0600, Jonathan Corbet wrote:
> On Wed, 18 May 2016 06:55:45 -0700 Kees Cook  wrote:
> > A common misspelling of "interruptible" is "interruptable". This fixes
> > them in the tree and adds the two most common variations to spelling.txt.

$ grep --include=*.[ch] -Proh "\b[A-Za-z]+[ai]ble\b" * | \
  tr [:upper:] [:lower:] | sort | uniq

gives several more that could be updated like:

avaiable
avaialable
avaible
available
availible
availlable
avalable
avalaible
avaliable
avalible
avalilable
aviable
avialable
avilable
[]
preemptable
preemptible
preemtible
[]
responsable
responsible
resposible
[]
unwritable
unwriteable
unwrittable
updatable
updateable
upgradable
upgradeable


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html