From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] [PATCH userspace-rcu] document the call_rcu() family of primitives
Date: Wed, 1 Jun 2011 10:37:41 -0400 [thread overview]
Message-ID: <BLU0-SMTP88A176F0561AE2498D1C49967D0@phx.gbl> (raw)
In-Reply-To: <20110601000120.GA2393@linux.vnet.ibm.com>
* Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> On Tue, May 31, 2011 at 05:51:53PM -0400, Mathieu Desnoyers wrote:
> > * Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> > > Just in case documentation is desired. ;-)
> > >
> > > Thanx, Paul
> > >
> > > ------------------------------------------------------------------------
> > >
> > > Document the new call_rcu() primitives.
> > >
> > > Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> > >
> > > diff --git a/README b/README
> > > index 7d97f19..0e5ad47 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -139,6 +139,79 @@ Usage of liburcu-defer
> > > * Its API is currently experimental. It may change in future library
> > > releases.
> > >
> > > +Usage of urcu-call-rcu
> > > +
> > [...]
> > > +
> > > + These primitives may be combined to set up pretty much any desired
> > > + association between worker and call_rcu() helper threads. If
> > > + a given executable calls only call_rcu(), then that executable
> > > + will have only the single global default call_rcu() helper
> > > + thread. This will suffice in most cases.
> >
> > Hi Paul,
> >
> > It might be good to keep the information at a level appropriate for
> > people wanting to familiarize themself with the library. Most
> > importantly, I don't want people to run away screaming when they see the
> > full set of options when all they really need is to simply do:
> >
> > #include <urcu-call-rcu.h>
> >
> > add struct rcu_head structures and pass them to
> >
> > call_rcu(...);
> >
> > into their code along with a callback.
> >
> > We could lift out the rest of the discussion about the various detailed
> > tweaks into a separate document.
> >
> > How does that sound ?
>
> Sounds reasonable.
>
> Where should the separate document go? One approach is docbook headers.
> Another is something like an API.txt. Thoughts?
We might as well start simple first with API.txt, and then switch to
docbook when we see the need for it ?
Mathieu
>
> Thanx, Paul
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
parent reply other threads:[~2011-06-01 14:37 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20110601000120.GA2393@linux.vnet.ibm.com>]
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=BLU0-SMTP88A176F0561AE2498D1C49967D0@phx.gbl \
--to=compudj@krystal.dyndns.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