spelling fixes: arch/x86_64/
PATCH 1/1 spelling fixes: arch/x86_64/
Spelling fixes in arch/x86_64/.
---
arch/x86_64/boot/compressed/misc.c | 4 ++-- arch/x86_64/kernel/hpet.c | 2 +- arch/x86_64/kernel/io_apic.c | 4 ++-- arch/x86_64/kernel/mce.c | 4 ++-- arch/x86_64/kernel/signal.c | 2 +- arch/x86_64/kernel/smpboot.c | 2 +- arch/x86_64/kernel/suspend.c | 7 ++++++- arch/x86_64/kernel/traps.c | 2 +- arch/x86_64/kernel/vsyscall.c | 2 +- arch/x86_64/mm/fault.c | 4 ++-- arch/x86_64/mm/srat.c | 2 +- 11 files changed, 20 insertions(+), 15 deletions(-)
arch/x86_64/boot/compressed/misc.c +0 -0
@@ -25,7 +25,7 @@
/*
* Getting to provable safe in place decompression is hard.
- * Worst case behaviours need to be analized.
+ * Worst case behaviours need to be analyzed.
* Background information:
*
* The file layout is:
@@ -94,7 +94,7 @@
* Adding 32768 instead of 32767 just makes for round numbers.
* Adding the decompressor_size is necessary as it musht live after all
* of the data as well. Last I measured the decompressor is about 14K.
- * 10K of actuall data and 4K of bss.
+ * 10K of actual data and 4K of bss.
*
*/
arch/x86_64/kernel/hpet.c +0 -0
@@ -163,7 +163,7 @@ int hpet_arch_init(void)
/*
* hpet period is in femto seconds per cycle
* so we need to convert this to ns/cyc units
- * aproximated by mult/2^shift
+ * approximated by mult/2^shift
*
* fsec/cyc * 1nsec/1000000fsec = nsec/cyc = mult/2^shift
* fsec/cyc * 1ns/1000000fsec * 2^shift = mult
arch/x86_64/kernel/io_apic.c +0 -0
@@ -1710,7 +1710,7 @@ __setup("no_timer_check", notimercheck);
/*
*
- * IRQ's that are handled by the PIC in the MPS IOAPIC case.
+ * IRQs that are handled by the PIC in the MPS IOAPIC case.
* - IRQ2 is the cascade IRQ, and cannot be a io-apic IRQ.
* Linux doesn't really care, as it's not actually used
* for any interrupt handling anyway.
@@ -1862,7 +1862,7 @@ void destroy_irq(unsigned int irq) }
/*
- * MSI mesage composition
+ * MSI message composition
*/
#ifdef CONFIG_PCI_MSI
static int msi_compose_msg(struct pci_dev *pdev, unsigned int irq, struct msi_msg *msg)
arch/x86_64/kernel/mce.c +0 -0
@@ -298,7 +298,7 @@ void do_machine_check(struct pt_regs * regs, long error_code)
#ifdef CONFIG_X86_MCE_INTEL
/***
* mce_log_therm_throt_event - Logs the thermal throttling event to mcelog
- * @cpu: The CPU on which the event occured.
+ * @cpu: The CPU on which the event occurred.
* @status: Event status information
*
* This function should be called by the thermal interrupt after the
@@ -573,7 +573,7 @@ static int __init mcheck_disable(char *str)
return 1; }
-/* mce=off disables machine check. Note you can reenable it later +/* mce=off disables machine check. Note you can re-enable it later
using sysfs.
mce=TOLERANCELEVEL (number, see above)
mce=bootlog Log MCEs from before booting. Disabled by default on AMD.
arch/x86_64/kernel/signal.c +0 -0
@@ -411,7 +411,7 @@ static void do_signal(struct pt_regs *regs)
signr = get_signal_to_deliver(&info, &ka, regs, NULL);
if (signr > 0) {- /* Reenable any watchpoints before delivering the
+ /* Re-enable any watchpoints before delivering the
* signal to user space. The processor register will
* have been cleared if the watchpoint triggered
* inside the kernel.
arch/x86_64/kernel/smpboot.c +0 -0
@@ -359,7 +359,7 @@ void __cpuinit start_secondary(void)
/*
* We need to hold call_lock, so there is no inconsistency
* between the time smp_call_function() determines number of
- * IPI receipients, and the time when the determination is made
+ * IPI recipients, and the time when the determination is made
* for which cpus receive the IPI in genapic_flat.c. Holding this
* lock helps us to not include this cpu in a currently in progress
* smp_call_function().
arch/x86_64/kernel/suspend.c +0 -0
@@ -123,7 +123,12 @@ void fix_processor_context(void)
int cpu = smp_processor_id(); struct tss_struct *t = &per_cpu(init_tss, cpu);
- set_tss_desc(cpu,t); /* This just modifies memory; should not be neccessary. But... This is neccessary, because 386 hardware has concept of busy TSS or some similar stupidity. */
+ /*
+ * This just modifies memory; should not be necessary.
+ * But... This is necessary, because 386 hardware has
+ * the concept of busy TSS or some similar stupidity.
+ */
+ set_tss_desc(cpu,t);
cpu_gdt(cpu)[GDT_ENTRY_TSS].type = 9;
arch/x86_64/kernel/traps.c +0 -0
@@ -199,7 +199,7 @@ static unsigned long *in_exception_stack(unsigned cpu, unsigned long stack,
#define MSG(txt) ops->warning(data, txt)
/*
- * x86-64 can have upto three kernel stacks: + * x86-64 can have up to three kernel stacks:
* process stack
* interrupt stack
* severe exception (double fault, nmi, stack fault, debug, mce) hardware stack
arch/x86_64/kernel/vsyscall.c +0 -0
@@ -54,7 +54,7 @@
/*
* vsyscall_gtod_data contains data that is :
* - readonly from vsyscalls
- * - writen by timer interrupt or systcl (/proc/sys/kernel/vsyscall64)
+ * - written by timer interrupt or systcl (/proc/sys/kernel/vsyscall64)
* Try to keep this structure as small as possible to avoid cache line ping pongs */
struct vsyscall_gtod_data_t {
arch/x86_64/mm/fault.c +0 -0
@@ -387,7 +387,7 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs, again:
/* When running in the kernel we expect faults to occur only to * addresses in user space. All other faults represent errors in the
- * kernel and should generate an OOPS. Unfortunatly, in the case of an
+ * kernel and should generate an OOPS. Unfortunately, in the case of an
* erroneous fault occurring in a code path which already holds mmap_sem
* we will deadlock attempting to validate the fault against the
* address space. Luckily the kernel only validly references user
@@ -395,7 +395,7 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs *regs,
* exceptions table.
*
* As the vast majority of faults will be valid we will only perform
- * the source reference check when there is a possibilty of a deadlock.
+ * the source reference check when there is a possibility of a deadlock.
* Attempt to lock the address space, if we cannot we then validate the
* source. If this is invalid we can skip the address space check,
* thus avoiding the deadlock.
arch/x86_64/mm/srat.c +0 -0
@@ -218,7 +218,7 @@ static inline int save_add_info(void) {return 0;}
/*
* Update nodes_add and decide if to include add are in the zone.
* Both SPARSE and RESERVE need nodes_add infomation.
- * This code supports one contigious hot add area per node.
+ * This code supports one contiguous hot add area per node.
*/
static int reserve_hotadd(int node, unsigned long start, unsigned long end) {
Signature · 4 lines
1.5.0.1 -- Simon Arlott
Review static void do_signal(struct pt_regs *regs) · line 414
Quoted 8 lines
+++
b/arch/x86_64/kernel/signal.c(quoted diff) +1
-1@@ -411,7 +411,7 @@ static void do_signal(struct pt_regs *regs) signr = get_signal_to_deliver(&info, &ka, regs, NULL); if (signr > 0) { - /* Reenable any watchpoints before delivering the + /* Re-enable any watchpoints before delivering the
reenable gets >140k google hits so it seems to be an really used word. Similar with upto.
-Andi
Quoted 4 lines
Review
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Andi" == Andi Kleen <[email protected]> writes:
(quoted diff) +1
-1- /* Reenable any watchpoints before delivering the + /* Re-enable any watchpoints before delivering the
Andi> reenable gets >140k google hits so it seems to be an really Andi> used word.
Essentially all commonly used English words which start out with hyphens loose them over time. It starts out with typos and progresses until the non-hyphenated form becomes the exclusively used form. It does seem that re-enable → reenable is occurring, based on those search hits.
Andi> Similar with upto.
I’ve a *much* harder time agreeing with «upto» in place of «up to». That should be treated as a typo in need of fixing.
-JimC
Signature · 1 line
James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
Quoted 7 lines · James Cloos
Quoted 4 lines
Review
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Andi" == Andi Kleen <[email protected]> writes:
(quoted diff) +1
-1- /* Reenable any watchpoints before delivering the + /* Re-enable any watchpoints before delivering theAndi> reenable gets >140k google hits so it seems to be an really Andi> used word.
Well you will find extensive "misuse" of all the re-e* words in english, but all should be hyphenated. Moreover, there is no license in english to just create new such words, you cannot re-entertain your guests for example. In practice we do allow creation of new re-e* words, as in re-execute, and that's probably ok in techno-jargon-speak.
But re-enable is an old and well used word, reenable is not, and I see no reason to encourage the latter incorrect use, since it is harder to read (double e after r at the start of the word is almost always a long e).
Note that in google, you always want to hyphenate. reenable will catch only the misuses, re-enable will catch both.
Quoted 5 lines
Essentially all commonly used English words which start out with hyphens loose them over time. It starts out with typos and progresses until the non-hyphenated form becomes the exclusively used form. It does seem that re-enable → reenable is occurring, based on those search hits.
Hyphens do sometimes disappear, but not for re-e*, OED version 2 does not allow a single such instance.
Quoted 5 lines
Andi> Similar with upto.
I’ve a *much* harder time agreeing with «upto» in place of «up to». That should be treated as a typo in need of fixing.
Indeed .. upto is not a word.
Quoted 2 lines
-JimC
Quoted 4 lines
Essentially all commonly used English words which start out with hyphens loose them over time. It starts out with typos and progresses until the non-hyphenated form becomes the exclusively used form. It does seem that re-enable → reenable is occurring, based on those search hits.
Re-enable is definitely "more correct".
Quoted 4 lines
Andi> Similar with upto.
I’ve a *much* harder time agreeing with «upto» in place of «up to». That should be treated as a typo in need of fixing.
The dictionary agrees.
Alan
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Alan" == Alan Cox <[email protected]> writes:
Alan> Re-enable is definitely "more correct".
I don't disagree. Had I been more awake I expect I'd've :^) made that more clear.
-JimC
Signature · 1 line
James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6