Trailing periods in kernel messages (was: [PATCH 6/6] tick: add a missing dot in prink)

[Frans Pop <elendil@planet.nl>]

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