From 9323e79f10e5f5d8fffc3b307776173ca11faeae Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Wed, 8 Jun 2022 19:38:47 +0100 Subject: Fix 'writeable' typos We have about 30 instances of the typo/variant spelling 'writeable', and over 500 of the more common 'writable'. Standardize on the latter. Change produced with: sed -i -e 's/\([Ww][Rr][Ii][Tt]\)[Ee]\([Aa][Bb][Ll][Ee]\)/\1\2/g' $(git grep -il writeable) and then hand-undoing the instance in linux-headers/linux/kvm.h. Most of these changes are in comments or documentation; the exceptions are: * a local variable in accel/hvf/hvf-accel-ops.c * a local variable in accel/kvm/kvm-all.c * the PMCR_WRITABLE_MASK macro in target/arm/internals.h * the EPT_VIOLATION_GPA_WRITABLE macro in target/i386/hvf/vmcs.h (which is never used anywhere) * the AR_TYPE_WRITABLE_MASK macro in target/i386/hvf/vmx.h (which is never used anywhere) Signed-off-by: Peter Maydell Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Stefan Weil Message-id: 20220505095015.2714666-1-peter.maydell@linaro.org --- accel/tcg/user-exec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'accel/tcg/user-exec.c') diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c index ac57324d4f..20ada5472b 100644 --- a/accel/tcg/user-exec.c +++ b/accel/tcg/user-exec.c @@ -101,10 +101,10 @@ MMUAccessType adjust_signal_pc(uintptr_t *pc, bool is_write) * Return true if the write fault has been handled, and should be re-tried. * * Note that it is important that we don't call page_unprotect() unless - * this is really a "write to nonwriteable page" fault, because + * this is really a "write to nonwritable page" fault, because * page_unprotect() assumes that if it is called for an access to - * a page that's writeable this means we had two threads racing and - * another thread got there first and already made the page writeable; + * a page that's writable this means we had two threads racing and + * another thread got there first and already made the page writable; * so we will retry the access. If we were to call page_unprotect() * for some other kind of fault that should really be passed to the * guest, we'd end up in an infinite loop of retrying the faulting access. -- cgit v1.2.3-55-g7522