From: Masanari Iida <standby24x7@gmail.com>
To: linux-kernel@vger.kernel.org, rdunlap@infradead.org,
corbet@lwn.net, linux-doc@vger.kernel.org
Cc: Masanari Iida <standby24x7@gmail.com>
Subject: [PATCH] Doc: ioctl: Fix typos in Documentation/ioctl
Date: Mon, 16 Nov 2015 20:07:37 +0900 [thread overview]
Message-ID: <1447672057-29270-1-git-send-email-standby24x7@gmail.com> (raw)
This patch fix some spelling typos in Documentation/ioctl.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
Documentation/ioctl/botching-up-ioctls.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt
index 45fe78c..cc30b14 100644
--- a/Documentation/ioctl/botching-up-ioctls.txt
+++ b/Documentation/ioctl/botching-up-ioctls.txt
@@ -122,7 +122,7 @@ Time, Waiting and Missing it
----------------------------
GPUs do most everything asynchronously, so we have a need to time operations and
-wait for oustanding ones. This is really tricky business; at the moment none of
+wait for outstanding ones. This is really tricky business; at the moment none of
the ioctls supported by the drm/i915 get this fully right, which means there's
still tons more lessons to learn here.
@@ -146,7 +146,7 @@ still tons more lessons to learn here.
ioctl restartable relative timeouts tend to be too coarse and can
indefinitely extend your wait time due to rounding on each restart.
Especially if your reference clock is something really slow like the display
- frame counter. With a spec laywer hat on this isn't a bug since timeouts can
+ frame counter. With a spec lawyer hat on this isn't a bug since timeouts can
always be extended - but users will surely hate you if their neat animations
starts to stutter due to this.
@@ -176,7 +176,7 @@ entails its own little set of pitfalls:
* Ensure that you have sufficient insulation between different clients. By
default pick a private per-fd namespace which forces any sharing to be done
- explictly. Only go with a more global per-device namespace if the objects
+ explicitly. Only go with a more global per-device namespace if the objects
are truly device-unique. One counterexample in the drm modeset interfaces is
that the per-device modeset objects like connectors share a namespace with
framebuffer objects, which mostly are not shared at all. A separate
--
2.6.2.402.g2635c2b
next reply other threads:[~2015-11-16 11:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 11:07 Masanari Iida [this message]
2015-11-16 16:33 ` Randy Dunlap
2015-11-20 23:54 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1447672057-29270-1-git-send-email-standby24x7@gmail.com \
--to=standby24x7@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®