Release/edition plans

Release/edition plans

[Paul E. McKenney]

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?

							Thanx, Paul

Re: Release/edition plans

[Junchang Wang]

Hi Paul,

Sorry for the late reply; I was overwhelmed by some other jobs in the
past weeks.

It sounds great that you will release out a new version by the end of
this year. I have some time in the following one and a half months and
is going to read through the book. I'm not an expert in this domain
yet but would be very happy to help improve the book :-). Please let
me if you have some suggestions; otherwise, I will read
chapter-by-chapter since next week.


Thanks,
--Junchang
On Fri, Oct 19, 2018 at 4:35 AM Paul E. McKenney <paulmck@linux.ibm.com> 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?
>
>                                                         Thanx, Paul
>

Re: Release/edition plans

[Paul E. McKenney]

Hello, Junchang,

I don't have any specific advise.  Reading it sequentially is a very
reasonable approach, as is preferentially reading sections of specific
interest to you.  You are the one doing the reading, so your choice.  ;-)

							Thanx, Paul

On Fri, Oct 19, 2018 at 11:07:34PM +0800, Junchang Wang wrote:
> Hi Paul,
> 
> Sorry for the late reply; I was overwhelmed by some other jobs in the
> past weeks.
> 
> It sounds great that you will release out a new version by the end of
> this year. I have some time in the following one and a half months and
> is going to read through the book. I'm not an expert in this domain
> yet but would be very happy to help improve the book :-). Please let
> me if you have some suggestions; otherwise, I will read
> chapter-by-chapter since next week.
> 
> 
> Thanks,
> --Junchang
> On Fri, Oct 19, 2018 at 4:35 AM Paul E. McKenney <paulmck@linux.ibm.com> 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?
> >
> >                                                         Thanx, Paul
> >
> 

Re: Release/edition plans

[Akira Yokosawa]

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. ;-)

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.

        Thanks, Akira

> 
> 							Thanx, Paul
> 

Re: Release/edition plans

[Paul E. McKenney]

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

Re: Release/edition plans

[Paul E. McKenney]

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