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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
