Re: Trailing periods in kernel messages
On Sat, 22 Dec 2007 15:04:16 +0100 Benny Amorsen <[EMAIL PROTECTED]> wrote: > 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. 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. signature.asc Description: PGP signature
Re: Trailing periods in kernel messages
[EMAIL PROTECTED] (Lennart Sorensen) writes: > 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: 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 -- 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/
Re: Trailing periods in kernel messages
[EMAIL PROTECTED] (Lennart Sorensen) writes: 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: 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 -- 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/
Re: Trailing periods in kernel messages
On Sat, 22 Dec 2007 15:04:16 +0100 Benny Amorsen [EMAIL PROTECTED] wrote: 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. 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. signature.asc Description: PGP signature
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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/ -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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! -- 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/
RE: Trailing periods in kernel messages
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 @ 0xfe00 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 :00:04.2: uhci_check_and_reset_hc: legsup = 0x2000 pci :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: :00:01.0 IO window: disabled. MEM window: f800-fddf 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 -- 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/
Re: Trailing periods in kernel messages
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. ;-) -- 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/
Re: Trailing periods in kernel messages
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
--
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/
Re: Trailing periods in kernel messages
> 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. -- 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/
Re: Trailing periods in kernel messages
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] :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 :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. -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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?
--
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/
Re: Trailing periods in kernel messages
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
--
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/
Re: Trailing periods in kernel messages
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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] :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 :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. -- 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/
Re: Trailing periods in kernel messages
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? -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/
Re: Trailing periods in kernel messages
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. ;-) -- 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/
RE: Trailing periods in kernel messages
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 @ 0xfe00 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 :00:04.2: uhci_check_and_reset_hc: legsup = 0x2000 pci :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: :00:01.0 IO window: disabled. MEM window: f800-fddf 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 -- 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/
Re: Trailing periods in kernel messages
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! -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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/ -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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.
--
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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 16:04:10 -0800 Joe Perches <[EMAIL PROTECTED]> wrote: > On Thu, 2007-12-20 at 22:08 +, 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 -- 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/
Re: Trailing periods in kernel messages
> 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.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: - 00099800 (usable) > [0.00] BIOS-e820: 00099800 - 000a (reserved) > [0.00] BIOS-e820: 000d6000 - 000d8000 (reserved) > [0.00] BIOS-e820: 000e - 0010 (reserved) > [0.00] BIOS-e820: 0010 - bf6b (usable) > [0.00] BIOS-e820: bf6b - bf6cc000 (ACPI data) > [0.00] BIOS-e820: bf6cc000 - bf70 (ACPI NVS) > [0.00] BIOS-e820: bf70 - c000 (reserved) > [0.00] BIOS-e820: f000 - f400 (reserved) > [0.00] BIOS-e820: fec0 - fec1 (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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 2007-12-20 at 22:08 +, 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 -- 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/
Re: Trailing periods in kernel messages
> 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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 22:08:53 +, 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 \ 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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 14:19:28 -0800 Andrew Morton wrote: > On Thu, 20 Dec 2007 21:54:11 + > 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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 21:54:11 + 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! -- 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/
Re: Trailing periods in kernel messages
On Thu, Dec 20, 2007 at 09:54:11PM +, 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.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00099800 (usable) [0.00] BIOS-e820: 00099800 - 000a (reserved) [0.00] BIOS-e820: 000d6000 - 000d8000 (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6b (usable) [0.00] BIOS-e820: bf6b - bf6cc000 (ACPI data) [0.00] BIOS-e820: bf6cc000 - bf70 (ACPI NVS) [0.00] BIOS-e820: bf70 - c000 (reserved) [0.00] BIOS-e820: f000 - f400 (reserved) [0.00] BIOS-e820: fec0 - fec1 (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 -- 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/
Re: Trailing periods in kernel messages
> 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 -- 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/
Re: Trailing periods in kernel messages
> 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") -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
> 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 -- 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/
Re: Trailing periods in kernel messages
From: Alan Cox <[EMAIL PROTECTED]> Date: Thu, 20 Dec 2007 21:07:41 + > 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. -- 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/
Re: Trailing periods in kernel messages
On Thu, 2007-12-20 at 21:07 +, 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. -- 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/
Re: Trailing periods in kernel messages
> 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 -- 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/
Re: Trailing periods in kernel messages
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
--
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/
Re: Trailing periods in kernel messages
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
--
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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 2007-12-20 at 21:07 +, 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. -- 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/
Re: Trailing periods in kernel messages
From: Alan Cox [EMAIL PROTECTED] Date: Thu, 20 Dec 2007 21:07:41 + 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. -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
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) -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
On Thu, Dec 20, 2007 at 09:54:11PM +, 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.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00099800 (usable) [0.00] BIOS-e820: 00099800 - 000a (reserved) [0.00] BIOS-e820: 000d6000 - 000d8000 (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6b (usable) [0.00] BIOS-e820: bf6b - bf6cc000 (ACPI data) [0.00] BIOS-e820: bf6cc000 - bf70 (ACPI NVS) [0.00] BIOS-e820: bf70 - c000 (reserved) [0.00] BIOS-e820: f000 - f400 (reserved) [0.00] BIOS-e820: fec0 - fec1 (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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 21:54:11 + 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! -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 14:19:28 -0800 Andrew Morton wrote: On Thu, 20 Dec 2007 21:54:11 + 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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 22:08:53 +, 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 -- 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/
Re: Trailing periods in kernel messages
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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 2007-12-20 at 22:08 +, 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 -- 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/
Re: Trailing periods in kernel messages
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.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00099800 (usable) [0.00] BIOS-e820: 00099800 - 000a (reserved) [0.00] BIOS-e820: 000d6000 - 000d8000 (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6b (usable) [0.00] BIOS-e820: bf6b - bf6cc000 (ACPI data) [0.00] BIOS-e820: bf6cc000 - bf70 (ACPI NVS) [0.00] BIOS-e820: bf70 - c000 (reserved) [0.00] BIOS-e820: f000 - f400 (reserved) [0.00] BIOS-e820: fec0 - fec1 (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 -- 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/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 16:04:10 -0800 Joe Perches [EMAIL PROTECTED] wrote: On Thu, 2007-12-20 at 22:08 +, 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 -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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. -- 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/
Re: Trailing periods in kernel messages
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) {
-
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/
Re: Trailing periods in kernel messages
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. - 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/
Re: Trailing periods in kernel messages
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 - 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/
Re: Trailing periods in kernel messages
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 :) - 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/
Re: Trailing periods in kernel messages (was: [PATCH 6/6] tick: add a missing dot in prink)
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. - 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/
Trailing periods in kernel messages (was: [PATCH 6/6] tick: add a missing dot in prink)
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: - 0009fc00 (usable)
[...]
ACPI: RSDP 000FE020, 0014 (r0 INTEL )
ACPI: RSDT 7F6FDE48, 0058 (r1 INTEL D945GCZ FF9 MSFT 113)
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: 0xfed0
[...]
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/
Trailing periods in kernel messages (was: [PATCH 6/6] tick: add a missing dot in prink)
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: - 0009fc00 (usable) [...] ACPI: RSDP 000FE020, 0014 (r0 INTEL ) ACPI: RSDT 7F6FDE48, 0058 (r1 INTEL D945GCZ FF9 MSFT 113) 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: 0xfed0 [...] 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/
Re: Trailing periods in kernel messages (was: [PATCH 6/6] tick: add a missing dot in prink)
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. - 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/
Re: Trailing periods in kernel messages
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 :) - 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/
Re: Trailing periods in kernel messages
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 - 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/
Re: Trailing periods in kernel messages
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) {
-
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/
Re: Trailing periods in kernel messages
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. - 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/
