From: "Thomas H.P. Andersen" <phomes@gmail.com>
To: linux-hotplug@vger.kernel.org
Subject: [PATCH] README: typo fixes
Date: Mon, 20 Jan 2014 20:11:35 +0000 [thread overview]
Message-ID: <1390248695-2772-1-git-send-email-phomes@gmail.com> (raw)
From: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
---
For libabc
README | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/README b/README
index bb06cad..f1a505d 100644
--- a/README
+++ b/README
@@ -36,17 +36,17 @@ Why bother?
nice, and give them what they are used to. It makes their life a
lot easier.
-use autotools
+Use autotools
- Every custom config/makefile/build system is worse for everybody
than autotools is.
- We are all used to autotools, it works, nobody cares.
- It's only two simple files to edit and include in git, which are
well understood by many many people, not just you.
- - Ignore all crap autotools create in the source tree. never check
+ - Ignore all crap autotools create in the source tree. Never check
the created files into git.
- Never, ever, install config.h. That's internal to your sources
and is nothing to install.
- - And really, anything but autotools is realy an option. Just get
+ - And really, nothing but autotools is really an option. Just get
over it. Everything else is an experiment, and it will come back
to you sooner or later. Why? think cross compilation, installation/
uninstallation, build root integration, separate object trees,
@@ -73,11 +73,11 @@ Zero global state -- Make your library threads-aware, but *not* thread-safe!
*every* program has loadable modules, think NSS!
- Avoid locking and mutexes, they are very unlikely to work correctly,
and incredibly hard to get right.
- - Always use a library context object. every thread should then
+ - Always use a library context object. Every thread should then
operate on its own context. Do not imply context objects via TLS. It
won't work. TLS inheritance to new threads will get in your way. TLS
is a problem in itself, not a solution.
- - Do not use gcc constructors, or destructors, you can only loose if
+ - Do not use gcc constructors, or destructors, you can only lose if
you do. Do not use _fini() or _ini(), don't even use your own
explicit library initializer/destructor functions. It just won't
work if your library is pulled in indirectly from another library
@@ -198,7 +198,7 @@ Update NEWS to let developers know what has changed
- If you want to provide ChangeLog, use the one generated
by git, do not maintain your own.
-use standard types
+Use standard types
- The kernel's u8, u16, ... correspond to uint8_t, uint16_t in
userspace from <inttypes.h>. Don't define your own typedefs
for that, don't include the kernel types in common headers.
--
1.8.4.2
reply other threads:[~2014-01-20 20:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1390248695-2772-1-git-send-email-phomes@gmail.com \
--to=phomes@gmail.com \
--cc=linux-hotplug@vger.kernel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).