From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: Release/edition plans
Date: Tue, 30 Oct 2018 15:33:56 -0700 [thread overview]
Message-ID: <20181030223356.GA9149@linux.ibm.com> (raw)
In-Reply-To: <20181028171645.GM4170@linux.ibm.com>
On Sun, Oct 28, 2018 at 10:16:45AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 29, 2018 at 12:19:56AM +0900, Akira Yokosawa wrote:
> > On 2018/10/18 13:34:14 -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I would normally have done a perfbook release by now, given that the last
> > > one was in November 2017. My lame excuse is that creating 340 RCU/LKMM
> > > patches thus far this year turned out to be a bit harder than it looks.
> > >
> > > My current thought is to get a release out in the next month or two,
> > > and to get the second edition out in 2019.
> > >
> > > Thoughts?
> >
> > I'd like to know your rough plan to reflect the LKMM/RCU updates to
> > perfbook. Those updates affect mostly Chapter 15 and Section 9.5.
> >
> > I understand that perfbook will keep slightly out-of-date because of
> > the always moving goal post. ;-)
>
> Indeed! My thought was to add the locking portions of LKMM once plain
> accesses have been added, but please see below. I don't believe that
> perfbook's wording was precise enough to care about the release-acquire
> strengthening. SRCU and reader-writer locking are on the way, but it
> might be some time. Anything else that I am missing?
Alpha now respects dependent reads, so I am also updating this. ;-)
> I guess I should add RCU litmus tests to the formal-verification chapter
> under the Axiomatic Approaches section, with forward references to the
> memory-ordering chapter, and ditto for locking. I would then add forward
> references from the locking chapter and RCU section to this material.
Which are now there.
Thanx, Paul
> On RCU itself, I need to reflect the merging of the bh, preempt, and
> sched flavors (and also provide an updated LWN article on the RCU API).
> Also the disappearance of synchronize_rcu_mult(). I would also like to
> get some material from the Issaquah Challenge incorporated, though no
> promises on that one. Anything else? (Yes, I review the Linux-kernel
> API each time to find things.)
>
> I would not delay a release for any of the above, but I should have a
> fair fraction done for the edition. There is always a reason to delay,
> so some balance is required.
>
> > Also, update of Style Guide is in my todo list to explain the new scheme
> > of code snippet handled by fancyvrb. Hopefully, that can be done in a month
> > or so.
> >
> > OTOH, actual conversion of code snippets can take much longer. Labeling
> > lines in snippets is not trivial and can only be done one by one.
> > No need to harry in this respect, I suppose.
>
> I would not delay a release for either of these, though my travel
> plans make it unlikely that I will release before the end of November
> in any case. I hope to get significant time to work on perfbook near
> the end of the year as well.
>
> I expect to release an electronic edition first, then a print edition
> a few months later. The electronic edition convinces some people to
> take a close look, and their feedback improves the print edition. At
> least that is what happened last time.
>
> Thoughts?
>
> Thanx, Paul
prev parent reply other threads:[~2018-10-31 7:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 20:34 Release/edition plans Paul E. McKenney
2018-10-19 15:07 ` Junchang Wang
2018-10-19 18:19 ` Paul E. McKenney
2018-10-28 15:19 ` Akira Yokosawa
2018-10-28 17:16 ` Paul E. McKenney
2018-10-30 22:33 ` Paul E. McKenney [this message]
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=20181030223356.GA9149@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=akiyks@gmail.com \
--cc=perfbook@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