tick: add a missing dot in prink

Add a missing '.' in prink information.

---
 kernel/time/tick-oneshot.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index 0258d31..0b5e513 100644
@@ -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

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.

Exactly because kernel messages are in general _not_ sentences. IMO trailing periods

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.

Exactly why I make an exception for those in my proposal.

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

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

:)

Inequivalent.

Try:

	grep -rP --include=*.[ch] 'printk.*\.\\n' * | wc -l
and
	grep -rp --include=*.[ch] 'printk.*[^\.]\\n' * | wc -l

6k/38k

cheers, Joe

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.

I hope these will eventually disappear.

Perhaps that's a good idea.

index cbb4258..707f84c 100755
@@ -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) {

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

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

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

Properly it should have a full stop after the table.

^Subject ^ Verb

^ Subject ^Verb
etc

Not all are sentences but many are including some of your examples, and they should have full stops therefore.

Alan

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!

IMO if checkpatch contains a check for trailing periods, it should only be part of the strict/pedantic checks.
But it's not needed.

---
~Randy

I was assuming they would go to the trivial patches maintainer, that's what the poor man is there for.

Alan

'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

From: Alan Cox <[email protected]>
Date: Thu, 20 Dec 2007 21:07:41 +0000

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.

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 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

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...

- 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

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

Its the closest thing there is to a definitive reference to the English language as a whole.

Alan

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

"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?

+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)

Well, the kernel log messages are programs, the kind that are for humans trying to analyze a problem.

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

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.

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.

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

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

It's simply the imperative. You can make perfectly good English sentences in just one word -- "Eat." is an example. See more at
http://en.wikipedia.org/wiki/Imperative_mood.

It is a bit of a mystery why the kernel is ordering me to initialize the current offset of xfs_file_readdir though. I don't know how to do that, so I guess it's lucky that I don't use XFS. Who knows what would happen if I didn't correctly initialize xfs_file_readdir.

/Benny

I thinks it's not the kernel ordering you, it's the developer ordering the kernel to initialize that variable - presumably, because when it didn't do that, things broke.

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

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/

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'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

I have never heard of a compiler expressing the least concern over whitespace and other aspects of coding style.

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.

This wants fixing.

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.