Re: Release/edition plans

["Paul E. McKenney" <paulmck@linux.ibm.com>]

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?

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.

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