[PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Samuel Thibault]

Replace Configure with Enable in description of MAXSMP

The "Configure" word tends to make user believe they have to say 'yes'
to be able to choose the number of procs/nodes.  "Enable" should be
unambiguous enough.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ac7827f..cea0cd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -754,11 +754,11 @@ config IOMMU_API
 	def_bool (AMD_IOMMU || DMAR)
 
 config MAXSMP
-	bool "Configure Maximum number of SMP Processors and NUMA Nodes"
+	bool "Enable Maximum number of SMP Processors and NUMA Nodes"
 	depends on X86_64 && SMP && DEBUG_KERNEL && EXPERIMENTAL
 	select CPUMASK_OFFSTACK
 	---help---
-	  Configure maximum number of CPUS and NUMA Nodes for this architecture.
+	  Enable maximum number of CPUS and NUMA Nodes for this architecture.
 	  If unsure, say N.
 
 config NR_CPUS

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Linus Torvalds]

On Sat, Aug 21, 2010 at 12:32 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
>
> Replace Configure with Enable in description of MAXSMP
>
> The "Configure" word tends to make user believe they have to say 'yes'
> to be able to choose the number of procs/nodes.  "Enable" should be
> unambiguous enough.

What broken patch-generation tools do you use, btw? Nick Piggin has
the same problem: the Subject of the patch gets repeated as the first
line of the body of the thing, which is very annoying. Either I have
to go in and edit the email (which I try to do), or the thing gets
repeated in the commit message.

Yes, the summary line is interesting, but it's _not_ interesting
enough that people want to see it twice.

(See commit 99b7db7b8ffd for an example of where it got repeated twice
- Al Viro isn't as anal as me about commit messages, and clearly
didn't edit the email before applying it).

If you want to repeat the summary line, please repeat the "Subject:"
part of the line too, so that the tools automatically see that it's
just a repeat of the Subject: line. Same goes if you want to add
author information: make sure that the author information has that
"From: " prepended to it.

And if it really is a tool that creates these buggy patch messages
with duplicate summary information, please let's just fix that buggy
crud.

I edited this by hand, but it annoys me when I have to do mindless
silly stuff just because people submit broken patch descriptions.

                                   Linus

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Samuel Thibault]

Linus Torvalds, le Sat 21 Aug 2010 12:45:12 -0700, a écrit :
> What broken patch-generation tools do you use, btw?

Well, git diff actually :) But then editted by hand.

> Nick Piggin has the same problem: the Subject of the patch gets
> repeated as the first line of the body of the thing, which is very
> annoying.

Ah, I didn't realize you scripts include the subject topic too. Maybe it
should be said in SubmittingPatches that the "summary phrase" shouldn't
be repeated in the body.

Samuel

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Sam Ravnborg]

> 
> Ah, I didn't realize you scripts include the subject topic too. Maybe it
> should be said in SubmittingPatches that the "summary phrase" shouldn't
> be repeated in the body.

>From said document:
15) The canonical patch format

The canonical patch subject line is:

    Subject: [PATCH 001/123] subsystem: summary phrase

The canonical patch message body contains the following:

  - A "from" line specifying the patch author.

  - An empty line.

  - The body of the explanation, which will be copied to the
    permanent changelog to describe this patch.

  - The "Signed-off-by:" lines, described above, which will
    also go in the changelog.

  - A marker line containing simply "---".

  - Any additional comments not suitable for the changelog.

  - The actual patch (diff output).

That should do it. We cannot tell what should NOT be done.

If you use git then it is trivial to commit your changes and
generate patches using "git format-patch ..."

	Sam

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Samuel Thibault]

Sam Ravnborg, le Sat 21 Aug 2010 22:05:28 +0200, a écrit :
> The canonical patch subject line is:
> 
>     Subject: [PATCH 001/123] subsystem: summary phrase
> 
>   - The body of the explanation, which will be copied to the
>     permanent changelog to describe this patch.
> 
> That should do it. We cannot tell what should NOT be done.

Yes, but according to what is above, we need to repeat the subject,
else it won't be in the changelog.  Actually, this is probably where it
should be said 'do not repeat the subject, it will already be included'.

> If you use git then it is trivial to commit your changes and
> generate patches using "git format-patch ..."

That's just one case. See above for the general case.

Samuel

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Linus Torvalds]

On Sat, Aug 21, 2010 at 1:05 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>
> From said document:
> 15) The canonical patch format
>
> The canonical patch subject line is:
>
>    Subject: [PATCH 001/123] subsystem: summary phrase
>
> The canonical patch message body contains the following:
>
>  - A "from" line specifying the patch author.

Btw, git (and other systems, at least Andrew's patchqueue) also accepts

 - a Subject: line to repeat the subject. This can be useful if you
(for example) want to keep the actual email subject in an old thread,
and thus want to override the email Subject: line with one that is
appropriate for the patch itself.

 - a "Date: " line to specify the date of the patch. Not that most
people care, but when patches get forwarded by email and sign-off's
added, the date of the newer email will obviously change. So _if_ you
care about the date when you actually sent out the patch, you can add
the Date: line to specify the date of the submission, and then as
people forward it, that one may stay around (because it is in the body
of the email)

Quite frankly, I don't personally much care for the "date" line, and
it easily gets lost if a patch is maintained not in email, but in some
other patch queue system (so I think the date line gets dropped if the
patch goes through Andrew, for example). But a patch queue that
doesn't honor the summary and author information isn't a patch queue,
it's a broken mess.

Putting the author line ("From: xyz <abc@example.com>") at the top of
the email body is always a good idea, though. That means that other
people can forward the email, without accidentally then becoming
marked as the author. Of course, careful people will make sure to save
authorship anyway, but mistakes have happened.

(Of course, if you send the patch directly to me or Andrew, you don't
really need to. We both make sure that author information gets saved
off. It tends to be people who aren't quite as used to emailed patches
that get this wrong).

                                    Linus

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Linus Torvalds]

On Sat, Aug 21, 2010 at 1:16 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sat, Aug 21, 2010 at 1:05 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>>
>> The canonical patch message body contains the following:
>>
>>  - A "from" line specifying the patch author.
>
> Btw, git (and other systems, at least Andrew's patchqueue) also accepts
>
>  - a Subject: line [...]
>
>  - a "Date: " line [...]

So Arjan just sent out a patch that does all three. See

  http://lkml.indiana.edu/hypermail/linux/kernel/1008.2/02557.html

for an example.

And note that all those three lines can be dropped. In the absence of
the small "fake email header" at the top of the email body, git (and
again: also other mail applicator tools like the ones Andrew uses)
will take the information from the real email headers. So putting them
in the body is by no means required, but in the body they do end up
being more likely to not be corrupted by further emailing.

It's also a way to fix up a broken email system, for example. Lots of
people have email accounts that screw up their names (interesting
utf-8 characters being turned into regular ascii - for Finns, 'ä'
might be turned into 'a' or 'ae', for example), or maybe you want to
use your work email in the kernel logs, but you're using your home
email to send out the patch etc.

So sometimes the "put the header info at the top of the body" works as
a way to fix up incorrect information in your email headers.

                        Linus

Re: [PATCH,TRIVIAL] Replace Configure with Enable in description of MAXSMP

[Nick Piggin]

On Sat, Aug 21, 2010 at 12:45:12PM -0700, Linus Torvalds wrote:
> On Sat, Aug 21, 2010 at 12:32 PM, Samuel Thibault
> <samuel.thibault@ens-lyon.org> wrote:
> >
> > Replace Configure with Enable in description of MAXSMP
> >
> > The "Configure" word tends to make user believe they have to say 'yes'
> > to be able to choose the number of procs/nodes.  "Enable" should be
> > unambiguous enough.
> 
> What broken patch-generation tools do you use, btw? Nick Piggin has
> the same problem: the Subject of the patch gets repeated as the first
> line of the body of the thing, which is very annoying. Either I have
> to go in and edit the email (which I try to do), or the thing gets
> repeated in the commit message.

I'm sorry about that :( I did try applying it here locally which seemed
to work, but something obviously went wrong between then and sending it.