Add a missing '.' in prink information.
Signed-off-by: Li Zefan <[email protected]>
---
kernel/time/tick-oneshot.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-oneshot.c b/kernel/time/tick-oneshot.c
index 0258d31..0b5e513 100644
--- a/kernel/time/tick-oneshot.c
+++ b/kernel/time/tick-oneshot.c
@@ -78,7 +78,7 @@ int tick_switch_to_oneshot(void (*handler)(struct clock_event_device *))
printk(KERN_INFO "Clockevents: "
"could not switch to one-shot mode:");
if (!dev) {
- printk(" no tick device\n");
+ printk(" no tick device.\n");
} else {
if (!tick_device_is_functional(dev))
printk(" %s is not functional.\n", dev->name);
--
1.5.3.rc7
Li Zefan wrote:
> Add a missing '.' in prink information.
> - printk(" no tick device\n");
> + printk(" no tick device.\n");
I wonder if that is correct. CodingStyle says:
Chapter 13: Printing kernel messages
[...]
Kernel messages do not have to be terminated with a period.
I personally think that rule could be made a bit stricter as for example
dmesg output currently looks fairly inconsistent with some messages
terminated with a period while most messages are not and have been wondering
if I should file patches to _remove_ periods.
Maybe the rule should be changed to:
Kernel messages should not be terminated with a period, unless a single
message contains multiple sentences.
?
Cheers,
FJP
Frans Pop wrote:
> Li Zefan wrote:
>> Add a missing '.' in prink information.
>> - printk(" no tick device\n");
>> + printk(" no tick device.\n");
>
> I wonder if that is correct. CodingStyle says:
> Chapter 13: Printing kernel messages
> [...]
> Kernel messages do not have to be terminated with a period.
>
> I personally think that rule could be made a bit stricter as for example
> dmesg output currently looks fairly inconsistent with some messages
> terminated with a period while most messages are not and have been wondering
> if I should file patches to _remove_ periods.
>
> Maybe the rule should be changed to:
> Kernel messages should not be terminated with a period, unless a single
> message contains multiple sentences.
> ?
But why a kernel message should not be terminated with a period? It does no harm
at all. And if the message is a complete sentence, it's grammatical correct to
terminated with a period.
I think CodingStyle just says an ending period is not mandatory. It does not
discourage the ending period.
On Thursday 29 November 2007, Li Zefan wrote:
> Frans Pop wrote:
> > Li Zefan wrote:
> >> Add a missing '.' in prink information.
> >> - printk(" no tick device\n");
> >> + printk(" no tick device.\n");
> >
> > I wonder if that is correct. CodingStyle says:
> > Chapter 13: Printing kernel messages
> > [...]
> > Kernel messages do not have to be terminated with a period.
> >
> > I personally think that rule could be made a bit stricter as for
> > example dmesg output currently looks fairly inconsistent with some
> > messages terminated with a period while most messages are not and have
> > been wondering if I should file patches to _remove_ periods.
> >
> > Maybe the rule should be changed to:
> > Kernel messages should not be terminated with a period, unless a
> > single message contains multiple sentences.
> > ?
>
> But why a kernel message should not be terminated with a period?
Exactly because kernel messages are in general _not_ sentences.
IMO trailing periods
> It does no harm at all.
Well, for one it needlessly increases the size of log files.
It also IMO just looks weird to have a trailing period only for some
messages and it certainly is completely inappropriate for messages like:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[...]
ACPI: RSDP 000FE020, 0014 (r0 INTEL )
ACPI: RSDT 7F6FDE48, 0058 (r1 INTEL D945GCZ FF9 MSFT 1000013)
If I look at my current dmesg output, *only* 16 out of 543 line have a
trailing period, and in almost all cases they just looks out of place. See
some examples at the bottom of this mail.
> And if the message is a complete sentence, it's grammatical correct to
> terminated with a period.
Exactly why I make an exception for those in my proposal.
> I think CodingStyle just says an ending period is not mandatory. It does
> not discourage the ending period.
I feel that to improve consistency the CodingStyle should be clear about
when a period should and should not be used.
Some examples of IMO unneeded/inconsistent use of trailing periods:
Entering add_active_range(0, 521983, 521984) 3 entries of 3200 used
end_pfn_map = 521984
DMI 2.3 present.
ACPI: RSDP 000FE020, 0014 (r0 INTEL )
[...]
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed00000
[...]
hpet clockevent registered
TSC calibrated against HPET
time.c: Detected 3199.880 MHz processor.
Console: colour dummy device 80x25
[...]
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12)
[...]
pnp: the driver 'i8042 kbd' has been unregistered
pnp: the driver 'i8042 aux' has been unregistered
PNP: No PS/2 controller found. Probing ports directly.
[...]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
PCI-GART: No AMD northbridge found.
The last example shows the inconsistency very well. And in this case the
second line could easily be "reduced" to a regular message by using a
semicolon instead of a period between the "sentences".
This is already being done in a number of other messages, for example:
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
So I'd suggest to change those last three lines to (including some textual
improvements):
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq"; if that helps, please
post a report
PCI-GART: No AMD northbridge found
On Thu, 29 Nov 2007 11:20:18 +0100 Frans Pop <[email protected]> wrote:
> Well, for one it needlessly increases the size of log files.
> It also IMO just looks weird to have a trailing period only for some
> messages and it certainly is completely inappropriate for messages like:
I'll confess to stealthily deleting some of those periods when nobody is looking.
I don't find them to have any value and they do have some cost, including screen
real estate at the source-code level.
Andrew Morton wrote:
> On Thu, 29 Nov 2007 11:20:18 +0100 Frans Pop <[email protected]> wrote:
>
>> Well, for one it needlessly increases the size of log files.
>> It also IMO just looks weird to have a trailing period only for some
>> messages and it certainly is completely inappropriate for messages like:
>
> I'll confess to stealthily deleting some of those periods when nobody is looking.
> I don't find them to have any value and they do have some cost, including screen
> real estate at the source-code level.
>
>
Just a roughly grep:
# grep -r -P --include=*.[ch] 'printk.*\.\\n' * | wc -l
6025
# grep -r -P --include=*.[ch] '\.\\n' * | wc -l
12723
:)
On Fri, 2007-11-30 at 09:12 +0800, Li Zefan wrote:
> Just a roughly grep:
> # grep -r -P --include=*.[ch] 'printk.*\.\\n' * | wc -l
> 6025
> # grep -r -P --include=*.[ch] '\.\\n' * | wc -l
> 12723
Inequivalent.
Try:
grep -rP --include=*.[ch] 'printk.*\.\\n' * | wc -l
and
grep -rp --include=*.[ch] 'printk.*[^\.]\\n' * | wc -l
6k/38k
cheers, Joe
Joe Perches wrote:
> On Fri, 2007-11-30 at 09:12 +0800, Li Zefan wrote:
>> Just a roughly grep:
>> # grep -r -P --include=*.[ch] 'printk.*\.\\n' * | wc -l
>> 6025
>> # grep -r -P --include=*.[ch] '\.\\n' * | wc -l
>> 12723
>
> Inequivalent.
>
> Try:
> grep -rP --include=*.[ch] 'printk.*\.\\n' * | wc -l
> and
> grep -rp --include=*.[ch] 'printk.*[^\.]\\n' * | wc -l
>
> 6k/38k
>
My 2nd grep finds out how many strings are terminated with '.'.
Those strings may finally pass to prink().
So it doesn't deserve the effort to eliminate these periods, isn't it?
Or we can add a check to checkpatch.pl to prevent new ones.
On Fri, 2007-11-30 at 09:54 +0800, Li Zefan wrote:
> So it doesn't deserve the effort to eliminate these periods, isn't it?
I hope these will eventually disappear.
> Or we can add a check to checkpatch.pl to prevent new ones.
Perhaps that's a good idea.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index cbb4258..707f84c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1390,6 +1390,10 @@ sub process {
if ($line =~ /\*\s*\)\s*k[czm]alloc\b/) {
WARN("unnecessary cast may hide bugs, see http://c-faq.com/malloc/mallocnocast.html\n" . $herecurr);
}
+
+ if ($rawline =~ /(print|pr_(emerg|alert|crit|err|warning|notice|info|debug)).*\.\\n\"/) {
+ WARN("unnecessary period before newline\n" . $herecurr);
+ }
}
if ($chk_patch && !$is_patch) {
On Thu, Nov 29, 2007 at 06:35:28PM -0800, Joe Perches wrote:
> On Fri, 2007-11-30 at 09:54 +0800, Li Zefan wrote:
> > So it doesn't deserve the effort to eliminate these periods, isn't it?
>
> I hope these will eventually disappear.
>
> > Or we can add a check to checkpatch.pl to prevent new ones.
>
> Perhaps that's a good idea.
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index cbb4258..707f84c 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1390,6 +1390,10 @@ sub process {
> if ($line =~ /\*\s*\)\s*k[czm]alloc\b/) {
> WARN("unnecessary cast may hide bugs, see http://c-faq.com/malloc/mallocnocast.html\n" . $herecurr);
> }
> +
> + if ($rawline =~ /(print|pr_(emerg|alert|crit|err|warning|notice|info|debug)).*\.\\n\"/) {
> + WARN("unnecessary period before newline\n" . $herecurr);
> + }
I missed the context on this one. So this is checking for periods at
the end of messages for printk's. We would need something a little
cleverer to ensure we are only checking the contents of the string. But
eminently doable.
/me plays
Ok, yes this seems ok. Have added it for 0.13.
-apw
> I missed the context on this one. So this is checking for periods at
> the end of messages for printk's. We would need something a little
> cleverer to ensure we are only checking the contents of the string. But
> eminently doable.
>
> /me plays
>
> Ok, yes this seems ok. Have added it for 0.13.
Please remove it.
The kernel printk messages are sentences. English language sentences end
with a full stop. They are messages printed up for normal human beings to
read and they should therefore be properly written.
In fact you should warn if it ends with a newline without a full stop
unless the next line is continuation of quoted text because that suggests
a full stop has been missed out incorrectly.
Alan
On Thu, 2007-12-20 at 21:07 +0000, Alan Cox wrote:
> > I missed the context on this one. So this is checking for periods at
> > the end of messages for printk's. We would need something a little
> > cleverer to ensure we are only checking the contents of the string. But
> > eminently doable.
> >
> > /me plays
> >
> > Ok, yes this seems ok. Have added it for 0.13.
>
> Please remove it.
>
> The kernel printk messages are sentences. English language sentences end
> with a full stop. They are messages printed up for normal human beings to
> read and they should therefore be properly written.
Documentation/Coding Style
Chapter 13: Printing kernel messages
Kernel messages do not have to be terminated with a period.
From: Alan Cox <[email protected]>
Date: Thu, 20 Dec 2007 21:07:41 +0000
> The kernel printk messages are sentences. English language sentences end
> with a full stop. They are messages printed up for normal human beings to
> read and they should therefore be properly written.
I totally agree.
I think the incorrect grammar and lack of proper capitalization and
puntuation in the kernel messages and our changelog entries is totally
embarassing for a professional software project.
And I'm not talking about cases where someone is not a native speaker
and just needs some help to get it right. I'm talking about people
who are native speakers and nearly encourage phrase quality and style
that borders on teenager "innanet speak" in what we publish to the
entire world.
Some people just can't be bothered to hold down the shift key when
typing in the first letter of a word from time to time, I guess.
Laziness is the only reasonable explanation I can come up with.
And it's totally ironic (and moronic) because some of these same folks
are the ones who get all over people for whitespace and tabbing in
the code.
> Documentation/Coding Style
>
> Chapter 13: Printing kernel messages
>
> Kernel messages do not have to be terminated with a period.
This piece of the document is wrong. It should also be changed. I've no
idea how such a ludicrous statement ever got into the Coding Style but I
have never seen it discussed and an archive search suggests it just
sneaked in without any kind of approval and discussion the list.
Kernel messages are in English. Let us keep it that way. Missing
punctuation is equated by many parts of the English speaking world with
poor quality, sloppy products and low levels of education. These are not
things with which we wish to be associated IMHO.
NAK to the patch.
Alan
On Thu, 2007-12-20 at 13:51 -0800, David Miller wrote:
> > The kernel printk messages are sentences. English language sentences end
> > with a full stop. They are messages printed up for normal human beings to
> > read and they should therefore be properly written.
> I totally agree.
> I think the incorrect grammar and lack of proper capitalization and
> puntuation in the kernel messages and our changelog entries is totally
> embarassing for a professional software project.
I agree with the grammar, capitalization, punctuation desires.
I add spelling, intelligibility and consistency to that list.
I believe though that printk messages are not sentences but are
logging statements. Statements do not require full-stops.
Opinions, of course, vary.
cheers, Joe
> I think the incorrect grammar and lack of proper capitalization and
> puntuation in the kernel messages and our changelog entries is totally
> embarassing for a professional software project.
But I guess correct grammar and spelling in our mailing list
communication is not important to you ;)
- R.
(In case it's not clear: in standard English, "punctuation" has a 'c',
and "X and Y *are* Z" is strongly preferred to "X and Y is Z")
> I believe though that printk messages are not sentences but are
> logging statements. Statements do not require full-stops.
>
> Opinions, of course, vary.
I do not believe "opinions" are relevant here. Relevant would be cites
from respected style guides (Fowlers, Oxford Guide To Style et al.) to
show they do not need a full stop.
I've not found one, but I am open to references.
Alan
On Thu, Dec 20, 2007 at 09:54:11PM +0000, Alan Cox wrote:
> > Kernel messages do not have to be terminated with a period.
>
> This piece of the document is wrong. It should also be changed. I've no
> idea how such a ludicrous statement ever got into the Coding Style but I
> have never seen it discussed and an archive search suggests it just
> sneaked in without any kind of approval and discussion the list.
>
> Kernel messages are in English. Let us keep it that way. Missing
> punctuation is equated by many parts of the English speaking world with
> poor quality, sloppy products and low levels of education. These are not
> things with which we wish to be associated IMHO.
Um, what? Kernel messages are *not* in English.
Take a look at a machine after it is freshly booted. The following
messages are *not* English:
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 0000000000099800 (usable)
[ 0.000000] BIOS-e820: 0000000000099800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000d6000 - 00000000000d8000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6b0000 (usable)
[ 0.000000] BIOS-e820: 00000000bf6b0000 - 00000000bf6cc000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bf6cc000 - 00000000bf700000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf700000 - 00000000c0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Do you really want to turn that into complete English sentences?
Or how about these?
[ 15.069322] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 15.069830] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[ 15.070448] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
[ 15.077264] TCP: Hash tables configured (established 131072 bind 65536)
[ 15.077278] TCP reno registered
[ 15.086122] checking if image is initramfs... it is
[ 15.846658] Freeing initrd memory: 7114k freed
Again, not sentences, and I don't think making every single printk a
gramatically valid sentence is a good thing. Or even necessary. And
in some cases, it would make the kernel messages harder to parse by an
automated log parser.
- Ted
On Thu, 20 Dec 2007 21:54:11 +0000
Alan Cox <[email protected]> wrote:
> > Documentation/Coding Style
> >
> > Chapter 13: Printing kernel messages
> >
> > Kernel messages do not have to be terminated with a period.
>
>
> This piece of the document is wrong. It should also be changed. I've no
> idea how such a ludicrous statement ever got into the Coding Style but I
> have never seen it discussed and an archive search suggests it just
> sneaked in without any kind of approval and discussion the list.
>
> Kernel messages are in English. Let us keep it that way. Missing
> punctuation is equated by many parts of the English speaking world with
> poor quality, sloppy products and low levels of education. These are not
> things with which we wish to be associated IMHO.
>
> NAK to the patch.
akpm:/usr/src/linux-2.6.24-rc5> grep -r '[^\.]\\n"' . | wc -l
105297
akpm:/usr/src/linux-2.6.24-rc5> grep -r '[\.]\\n"' . | wc -l
12743
For the record, I won't be taking any "add period to printk" patches.
akpm:/usr/src/linux-2.6.24-rc5> grep -r '[^\.]\\n"' net | wc -l
4978
akpm:/usr/src/linux-2.6.24-rc5> grep -r '[\.]\\n"' net | wc -l
493
Send 'em to Dave!
On Thu, 20 Dec 2007 14:19:28 -0800 Andrew Morton wrote:
> On Thu, 20 Dec 2007 21:54:11 +0000
> Alan Cox <[email protected]> wrote:
>
> > > Documentation/Coding Style
> > >
> > > Chapter 13: Printing kernel messages
> > >
> > > Kernel messages do not have to be terminated with a period.
> >
> >
> > This piece of the document is wrong. It should also be changed. I've no
> > idea how such a ludicrous statement ever got into the Coding Style but I
> > have never seen it discussed and an archive search suggests it just
> > sneaked in without any kind of approval and discussion the list.
> >
> > Kernel messages are in English. Let us keep it that way. Missing
> > punctuation is equated by many parts of the English speaking world with
> > poor quality, sloppy products and low levels of education. These are not
> > things with which we wish to be associated IMHO.
> >
> > NAK to the patch.
>
> akpm:/usr/src/linux-2.6.24-rc5> grep -r '[^\.]\\n"' . | wc -l
> 105297
> akpm:/usr/src/linux-2.6.24-rc5> grep -r '[\.]\\n"' . | wc -l
> 12743
>
> For the record, I won't be taking any "add period to printk" patches.
IMO if checkpatch contains a check for trailing periods, it should
only be part of the strict/pedantic checks.
But it's not needed.
> akpm:/usr/src/linux-2.6.24-rc5> grep -r '[^\.]\\n"' net | wc -l
> 4978
> akpm:/usr/src/linux-2.6.24-rc5> grep -r '[\.]\\n"' net | wc -l
> 493
>
> Send 'em to Dave!
---
~Randy
On Thu, 2007-12-20 at 22:08 +0000, Alan Cox wrote:
> I do not believe "opinions" are relevant here. Relevant would be cites
> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> show they do not need a full stop.
> I've not found one, but I am open to references.
What exactly is a guide other than an opinion?
I believe log entries are not exactly literature.
How does Fowler's applies to logs?
Other opinions/guides:
For:
http://nedbatchelder.com/text/log-style-guide.html
(though note the use of "good examples" without periods)
Against: (in lists)
http://home.comcast.net/~garbl/stylemanual/kthrul.htm
cheers, Joe
> For the record, I won't be taking any "add period to printk" patches.
> akpm:/usr/src/linux-2.6.24-rc5> grep -r '[^\.]\\n"' net | wc -l
> 4978
> akpm:/usr/src/linux-2.6.24-rc5> grep -r '[\.]\\n"' net | wc -l
> 493
>
> Send 'em to Dave!
I was assuming they would go to the trivial patches maintainer, that's
what the poor man is there for.
Alan
> Um, what? Kernel messages are *not* in English.
>
> Take a look at a machine after it is freshly booted. The following
> messages are *not* English:
>
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000000 - 0000000000099800 (usable)
> [ 0.000000] BIOS-e820: 0000000000099800 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000d6000 - 00000000000d8000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6b0000 (usable)
> [ 0.000000] BIOS-e820: 00000000bf6b0000 - 00000000bf6cc000 (ACPI data)
> [ 0.000000] BIOS-e820: 00000000bf6cc000 - 00000000bf700000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000bf700000 - 00000000c0000000 (reserved)
> [ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
> [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>
> Do you really want to turn that into complete English sentences?
Properly it should have a full stop after the table.
> Or how about these?
> [ 15.077264] TCP: Hash tables configured (established 131072 bind 65536)
^Subject ^ Verb
> [ 15.077278] TCP reno registered
^ Subject ^Verb
etc
> in some cases, it would make the kernel messages harder to parse by an
> automated log parser.
Not all are sentences but many are including some of your examples, and
they should have full stops therefore.
Alan
On Thu, 20 Dec 2007 22:08:53 +0000, Alan Cox <[email protected]> wrote:
> > I believe though that printk messages are not sentences but are
> > logging statements. Statements do not require full-stops.
> >
> > Opinions, of course, vary.
>
> I do not believe "opinions" are relevant here. Relevant would be cites
> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> show they do not need a full stop.
>
All those fine references you cite are sure written for read literate
(literacy?) texts. Punctuation is something that is needed in (just
forgive me 'cause I'm trying to think this in english, but spanish is
my native language...) continous written text that needs some kind of
symbol to show there is a pause half in a sentence (a comma), or that
two statements are separate sentences and need to be declaimed specially.
Nobody (someone?) has written a guide to declaim computer messages or
source code. If you get so picky, this message
[kajasldkjasl] Kernel OOPS: sdsdsdsdsd
shoud read:
At [kajasldkjasl], the kernel has tried to deliver an operation that
resulted in an inconsistent state, so system operation has been stopped...
>From my point of view:
- Kernel messages are not read at loud...
- If you are so worried about extra chars/mem usage in other areas, the
dot at the end of a kernel message is just trash.
- If some kernel message has two sentences, better to format them in
two lines (ie, sed -e :.:\n:g:)
If some kernel message needs grammatical corrections, it is not a kernel
message, it was someone very bored when he wrote the code.
The kernel messages are _not_ sentences, they are kernel messages.
If not, you have a harder work assuring they all have a subject and
a predicate than worrying about dots at the end...
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
On Thu, 20 Dec 2007 16:04:10 -0800
Joe Perches <[email protected]> wrote:
> On Thu, 2007-12-20 at 22:08 +0000, Alan Cox wrote:
> > I do not believe "opinions" are relevant here. Relevant would be cites
> > from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> > show they do not need a full stop.
> > I've not found one, but I am open to references.
>
> What exactly is a guide other than an opinion?
> I believe log entries are not exactly literature.
> How does Fowler's applies to logs?
Its the closest thing there is to a definitive reference to the English
language as a whole.
Alan
On Thursday 20 December 2007, Alan Cox wrote:
> The kernel printk messages are sentences.
I'm afraid that I completely and utterly disagree. Kernel messages are _not_
sentences. The vast majority is not well-formed and does not contain any of
the elements that are required for a proper sentence.
The most kernel messages can be compared to is a rather diverse and sloppy
enumeration. And enumerations follow completely different rules than
sentences. It can better be characterized as a "semi-random sequence of
context-sensitive technical messages".
IMHO the existing rule that "Kernel messages do not have to be terminated
with a period." is completely justified, though it does need some minor
clarification on the cases in which proper punctuation _should_ be
followed.
On Fri, 21 Dec 2007 02:43:33 +0100 Frans Pop <[email protected]> wrote:
> On Thursday 20 December 2007, Alan Cox wrote:
> > The kernel printk messages are sentences.
>
> I'm afraid that I completely and utterly disagree. Kernel messages are _not_
> sentences. The vast majority is not well-formed and does not contain any of
> the elements that are required for a proper sentence.
>
> The most kernel messages can be compared to is a rather diverse and sloppy
> enumeration. And enumerations follow completely different rules than
> sentences. It can better be characterized as a "semi-random sequence of
> context-sensitive technical messages".
>
> IMHO the existing rule that "Kernel messages do not have to be terminated
> with a period." is completely justified, though it does need some minor
> clarification on the cases in which proper punctuation _should_ be
> followed.
No-period is a kernel idiom, produces perfectly readable output, I have
never ever heard of anyone expressing the least concern over a lack of dots
at the end of their printks and 91% of kernel code agrees.
otoh the place where no-dots comes horridly unstuck is if a single printk
contains two sentences:
printk("My computer caught on fire. I hope yours does too\n");
that's really daft. It's very rare though.
Of course one could always patch syslogd to add the dots, or change printk
and add an i_am_anal=1 kernel boot option.
Andy, please have an accident with that checkpatch change and let's hope
like hell that nobody starts trying to "fix" any of this.
From: Andrew Morton <[email protected]>
Date: Thu, 20 Dec 2007 18:15:32 -0800
> No-period is a kernel idiom, produces perfectly readable output, I have
> never ever heard of anyone expressing the least concern over a lack of dots
> at the end of their printks and 91% of kernel code agrees.
I have never heard of a compiler expressing the least concern over
whitespace and other aspects of coding style.
Alan Cox <[email protected]> wrote:
>
> I do not believe "opinions" are relevant here. Relevant would be cites
> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> show they do not need a full stop.
>
> I've not found one, but I am open to references.
Well from where I come from, full stops are only used for complete
sentences. For example,
http://www.ballarat.edu.au/aasp/student/learning_support/generalguide/ch01s05s02.shtml
As to what is a complete sentence, that is debatable. However,
typically it would include a subject and a predicate. By this
rule the following line is not a complete sentence:
[XFS] Initialise current offset in xfs_file_readdir correctly
The reason is that it lacks a subject.
Of course I would completely agree that some kernel messages
are complete sentences and should have a full stop. However,
it is not clear to me that this is the case for all or even
most kernel printk messages.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Dec 21 2007 17:56, Herbert Xu wrote:
>>
>> I do not believe "opinions" are relevant here. Relevant would be cites
>> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
>> show they do not need a full stop.
>>
>> I've not found one, but I am open to references.
>
>Well from where I come from, full stops are only used for complete
>sentences.
>[...]
>As to what is a complete sentence, that is debatable. However,
>typically it would include a subject and a predicate. By this
>rule the following line is not a complete sentence:
>
> [XFS] Initialise current offset in xfs_file_readdir correctly
>
>The reason is that it lacks a subject.
"current offset" is your subject.
But I would tend to agree to "(most) kernel messages are not sentences."
Actually, I see it a bit different: (most) kernel messages are more like an
itemized list of what has been done/is going to be done. A *list*!
* water
* flour
* salt
* yeast or baking powder
* dough (obviously)
(I'm a programmer, not a cook.) Would you really add a fullstop?
>Of course I would completely agree that some kernel messages
>are complete sentences and should have a full stop.
+1. Those kernel messages which clearly have two or more sentences
obviously have sentences. ("If a device doesn't work, try "pci=routeirq".)
Can we get back to programming?
From: Jan Engelhardt <[email protected]>
Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
> Can we get back to programming?
Well, the kernel log messages are programs, the kind that are for
humans trying to analyze a problem.
On Dec 20 2007 18:15, Andrew Morton wrote:
>
>No-period is a kernel idiom, produces perfectly readable output, I have
>never ever heard of anyone expressing the least concern over a lack of dots
>at the end of their printks and 91% of kernel code agrees.
Let's check out some real-world messages, i.e. the ones you actually see:
11:12 ichi:~/Coding/linux-2.6_nosov > dmesg | grep '\.$'
[ 16.520364] Total of 1 processors activated (3334.94 BogoMIPS).
[ 16.746692] Completing Region/Field/Buffer/Package initialization:.............................................................................
[ 16.751681] Initializing Device/Processor/Thermal objects by executing _INI methods:.
[ 16.761402] Enabling SiS 96x SMBus.
[ 16.765700] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[ 16.768126] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[ 16.812932] Time: tsc clocksource has been installed.
[ 16.863799] IO window: disabled.
[ 16.993286] Machine check exception polling timer started.
[ 17.023249] isapnp: Scanning for PnP cards...
[ 17.484975] libata version 2.21 loaded.
[ 23.684850] 0000:00:04.0: Realtek RTL8201 PHY transceiver found at address 1.
[ 23.695501] eth0: SiS 900 PCI Fast Ethernet at 0xdc00, IRQ 19, 00:0a:e6:98:ed:d7.
[ 25.341019] nvidia: module license 'NVIDIA' taints kernel.
[ 63.215338] Netfilter messages via NETLINK v0.30.
[ 151.770648] /dev/vmmon[2792]: VMCI: Driver initialized.
[ 152.906489] /dev/vmnet: hub 0 does not exist, allocating memory.
[ 153.325793] /dev/vmnet: hub 1 does not exist, allocating memory.
[ 164.114371] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[ 164.114405] agpgart: SiS delay workaround: giving bridge time to recover.
[ 165.319145] Installing knfsd (copyright (C) 1996 [email protected]).
# vmware fills up dmesg. Shrug.
11:14 ichi:~/Coding/linux-2.6_nosov > dmesg|grep -v vmmon|wc -l
297
11:14 ichi:~/Coding/linux-2.6_nosov > dmesg|grep -v vmmon|grep '\.$' | wc -l
18
So yeah 91% is a good call.
> I'm afraid that I completely and utterly disagree. Kernel messages are _not_
> sentences. The vast majority is not well-formed and does not contain any of
> the elements that are required for a proper sentence.
This wants fixing.
> The most kernel messages can be compared to is a rather diverse and sloppy
> enumeration.
We fix sloppy things outside quotes we should fix them within quotes. A
lot of stuff is sentences or fully formed clauses that deserve
punctuating. I agree entirely that this is not always the case.
On Fri, Dec 21, 2007 at 11:10:38AM +0100, Jan Engelhardt wrote:
>
> > [XFS] Initialise current offset in xfs_file_readdir correctly
> >
> >The reason is that it lacks a subject.
>
> "current offset" is your subject.
In my school we were taught that "current offset" is part of the
predicate as opposed to the subject. This can be seen from the
fact that "offset" is singular while "initialise" did not take
on its third-person singular form of "initialises".
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Dec 21 2007 19:41, Herbert Xu wrote:
>On Fri, Dec 21, 2007 at 11:10:38AM +0100, Jan Engelhardt wrote:
>>
>> > [XFS] Initialise current offset in xfs_file_readdir correctly
>> >
>> >The reason is that it lacks a subject.
>>
>> "current offset" is your subject.
>
>In my school we were taught that "current offset" is part of the
>predicate as opposed to the subject. This can be seen from the
>fact that "offset" is singular while "initialise" did not take
>on its third-person singular form of "initialises".
o_O I better continue believing it is the subject. Because with
one extra word at the front, you can make this a "complete sentence":
Please initialize [the] current offset in xfs_file_readdir.
;-)
Jan Engelhardt wrote:
> On Dec 21 2007 17:56, Herbert Xu wrote:
> >>
> >> I do not believe "opinions" are relevant here. Relevant would be cites
> >> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> >> show they do not need a full stop.
> >>
> >> I've not found one, but I am open to references.
> >
> >Well from where I come from, full stops are only used for complete
> >sentences.
> >[...]
> >As to what is a complete sentence, that is debatable. However,
> >typically it would include a subject and a predicate. By this
> >rule the following line is not a complete sentence:
> >
> > [XFS] Initialise current offset in xfs_file_readdir correctly
> >
> >The reason is that it lacks a subject.
>
> "current offset" is your subject.
I hate to have to point this out, but "current offset" is the object, not
the subject. If the sentence was, "I have initialized the current offset in
xfs_file_readdir correctly.", then it would be quite clear that "I" is the
subject and "the current offset" is the object.
The log entry has an implied subject of "I" or, if you prefer, "the kernel".
It is not a complete sentence both because it implies the subject in a
context where English does not permit that and it lacks words required by
grammar (such as the "the" before "current offset"). It also lacks a helping
verb since it should be "have initialized" (or perhaps "initialized").
Sometime you can imply the subject, such as in, "Go home!". This is not one
of those cases. You cannot say "Am sleepy" to mean "I am sleepy", even
though it would seem perfectly reasonable to allow an implied subject,
English doesn't.
There is no reason log entries should be complete sentences. If you look at
a typical log, the complete sentences generally look worse than the
fragments.
For example:
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
and
EXT3 FS on hdc7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
And why the inconsistency in the beginning in both these examples?
Personally, I think a mix of sentences and statements is just fine.
Sentences should end with a period when it looks worse not to.
The following extracts from my log looks perfect to me:
Switched to high resolution mode on CPU 0
lp: driver loaded but no devices found
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.102
agpgart: Detected VIA Apollo Pro 133 chipset
agpgart: AGP aperture is 4M @ 0xfe000000
Entries that look imperfect to me include:
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Detected 1004.544 MHz processor.
ENABLING IO-APIC IRQs
EXT3-fs: INFO: recovery required on readonly filesystem.
Time: tsc clocksource has been installed.
The last one just looks wrong, even though it is a complete sentence.
Perhaps changing 'tsc' to 'TSC' will help or just saying "using TSC" or "TSC
enabled" would help.
Inconsistencies include:
PCI: VIA PCI bridge detected. Disabling DAC.
PCI: Enabling Via external APIC routing
pci 0000:00:04.2: uhci_check_and_reset_hc: legsup = 0x2000
pci 0000:00:04.2: Performing full reset
and
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
and
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: f8000000-fddfffff
More important than any hard and fast rules is just how it looks. Also
important is how it looks in context. For example, with the upper case and
lower case 'pci', either way is fine, but some of each doesn't look good.
Same for 'TCP'. Why does one message have a colon and not the others?
DS
David Miller wrote:
> From: Jan Engelhardt <[email protected]>
> Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
>
>> Can we get back to programming?
With respect to the vast majority of log messages, nobody confounded by
punctuation is truly trying to analyze a problem!
From: David Newall <[email protected]>
Date: Sat, 22 Dec 2007 00:13:07 +1030
> David Miller wrote:
> > From: Jan Engelhardt <[email protected]>
> > Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
> >
> >> Can we get back to programming?
>
> With respect to the vast majority of log messages, nobody confounded by
> punctuation is truly trying to analyze a problem!
And nobody confounded by whitespace and coding style is truly
interesting in writing properly functioning code!
I'm going to say it over and over again, everybody who thinks
this issue is different from coding style totally misses the
point.
And everyone who thinks this logging message issue stuff is a
non-issue yet will bash people over the head about coding style in
patch submissions is a hypocrite.
Jan Engelhardt wrote:
> On Dec 21 2007 17:56, Herbert Xu wrote:
>>As to what is a complete sentence, that is debatable. However,
>>typically it would include a subject and a predicate. By this
>>rule the following line is not a complete sentence:
>>
>> [XFS] Initialise current offset in xfs_file_readdir correctly
>>
>>The reason is that it lacks a subject.
>
> "current offset" is your subject.
It's an object, not the subject.
The quoted changelog heading is a complete sentence nevertheless, as it
is an imperative sentence. Its subject is implied.
It could end in a period or in an exclamation mark. But as it's
actually a heading, it doesn't have to and probably shouldn't.
--
Stefan Richter
-=====-=-=== ==-- =-=-=
http://arcgraph.de/sr/
David Miller wrote:
> From: David Newall <[email protected]>
> Date: Sat, 22 Dec 2007 00:13:07 +1030
>> David Miller wrote:
>>
>>> From: Jan Engelhardt <[email protected]>
>>> Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
>>>
>>>
>>>> Can we get back to programming?
>>>>
>> With respect to the vast majority of log messages, nobody confounded by
>> punctuation is truly trying to analyze a problem!
>>
>
> And nobody confounded by whitespace and coding style is truly
> interesting in writing properly functioning code!
>
I supposed you meant "interested." Proper coding style doesn't make for
proper code. Arguably, it aids when reading code, and that's why we
mostly stick to agreed standards; but it's hard to get worked up over a
dot at the end of a log message. In cases where it really does matter,
we make sure it's right; but demanding that every message meets some
unilateral idea of what is right is zealotry.
On Thu, Dec 20, 2007 at 01:43:04PM -0800, Joe Perches wrote:
> Documentation/Coding Style
>
> Chapter 13: Printing kernel messages
>
> Kernel messages do not have to be terminated with a period.
'do not have to' does not mean 'should not'. So the suggested patch
is wrong no matter what.
Prints of data and various tables would look silly with a period, but
sentences look better with it.
--
Len Sorensen
On Fri, Dec 21, 2007 at 12:55:16PM +0100, Jan Engelhardt wrote:
> o_O I better continue believing it is the subject. Because with
> one extra word at the front, you can make this a "complete sentence":
>
> Please initialize [the] current offset in xfs_file_readdir.
That still looks like an incomplete sentence, although orders are often
given in that form. Something like these seem more like complete
sentences:
You should initialize the current offset in xfs_file_readdir.
The driver will now initialize the current offset in xfs_file_readdir.
Where you or the driver is the subject. Then it makes sense. Of course
one would tend to assume the driver is just giving status reports so it
implicitly is the subject doing the things, even though there is no
actual sentence saying so.
It is more of the driver saying:
this driver is:
initializing the current offset in xfs_file_readdir
doing some other stuff
then doing some different stuff
etc
--
Len Sorensen