On 2017/10/28 06:23:17 -0700, Paul E. McKenney wrote:
> On Sat, Oct 28, 2017 at 05:16:56PM +0800, Yubin Ruan wrote:
>> On Sat, Oct 28, 2017 at 10:53:31AM +0900, Akira Yokosawa wrote:
>>> On 2017/10/28 17:06, Yubin Ruan wrote:
>>>> On Fri, Oct 27, 2017 at 04:05:49PM -0700, Paul E. McKenney wrote:
>>>>> On Sat, Oct 28, 2017 at 12:02:19AM +0900, Akira Yokosawa wrote:
>>>>>> Hi Yubin,
>>>>>>
>>>>>> On 2017/10/27 18:23, Yubin Ruan wrote:
>>>>>>> Hi paul,
>>>>>>>
>>>>>>> I finish chapter 7 and find some typo. Fixed in the patch below.
>>>>>>>
>>>>>>> Yubin
>>>>>>>
>>>>>>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
>>>>>>> index 9fcbbf9..c7c4ae8 100644
>>>>>>> --- a/locking/locking-existence.tex
>>>>>>> +++ b/locking/locking-existence.tex
>>>>>>> @@ -174,7 +174,7 @@ single partitionable data structure such as the hash table shown in the
>>>>>>> figure, it can be problematic if a given data element can be a member
>>>>>>> of multiple hash tables or given more-complex data structures such
>>>>>>> as trees or graphs.
>>>>>>> -These problems can be solved, in fact, such solutions form the basis
>>>>>>> +These problems can be solved. In fact, such solutions form the basis
>>>>>>
>>>>>> I'd suggest the following:
>>>>>>
>>>>>> +These problems can be solved, in fact, and such solutions form the basis
>>>>>
>>>>> How about this?
>>>>>
>>>>> Not only can these problems be solved, but the solutions also
>>>>> form the basis of lock-based software transactional memory [...].
>>>>
>>>> Thanks for your suggestion. I think Akira's approach looks more nature to me.
>>>> So, let me finish this little patch ;-)
>>>
>>> Well, I think Paul's suggestion is much clearer.
>>>
>>> BTW Yubin, your mail has a date field indicating it came from the near future:
>>>
>>>> Date: Sat, 28 Oct 2017 16:06:40 +0800
>>>
>>> May be time zone setting issue?
>>
>> Thanks Akira, I have correct the time configuration and modify the patch as
>> follow (as suggested by Paul)
>
> OK, thank you. But the way you say "as suggested by Paul" is as shown
> below, "Suggested-by". Not at all a big deal in my case, but it is
> good to get in practice so that you can help other people get patches
> in while still making sure that they get credit.
>
> Also, could you please use "git format-patch" and "git send-email"?
> Akira and I can help if the documentation has you confused.
I'm not sure I can help in the use of "git send-email".
Looks like Yubin did use "git format-patch" and appended the patch below
the "-----------" line, which is not recognized as scissors by "git am".
A line of "----8<-----" could be used instead.
> In the
> meantime, here are my notes to myself that I use to send out RCU
> patches.
>
> If you could redo and resend the patch, I would be very happy to accept it.
>
> ------------------------------------------------------------------------
> git format-patch -o <dir> -n --subject-prefix="PATCH -tip" <since>[..<until>]
>
> Create an email-ready patch. "-n" says to number them.
> Use "git send-email" to send them.
>
> For typical RCU patch from tip/core/rcu, something like:
>
> git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/rcu" to-mingo
> git format-patch -o /tmp/RCU -n --subject-prefix="PATCH RFC tip/core/rcu" to-mingo
> git format-patch -o /tmp/RCU -n --subject-prefix="PATCH tip/core/urgent" to-mingo
>
> For intended submissions, RFC submissions, and bug fixes,
> respectively.
>
> Then run scripts/checkpatch.pl on each file in /tmp/RCU:
>
> scripts/checkpatch.pl /tmp/RCU/*
>
> git send-email --no-chain-reply-to --to linux-kernel@xxxxxxxxxxxxxxx --cc email1@address1 --cc email2@address2 file1 file2 ...
>
> For typical RCU patch, check -next conflicts, then something like:
>
> mutt linux-kernel@xxxxxxxxxxxxxxx -c mingo@xxxxxxxxxx -c jiangshanlai@xxxxxxxxx -c dipankar@xxxxxxxxxx -c akpm@xxxxxxxxxxxxxxxxxxxx -c mathieu.desnoyers@xxxxxxxxxxxx -c josh@xxxxxxxxxxxxxxxx -c tglx@xxxxxxxxxxxxx -c peterz@xxxxxxxxxxxxx -c rostedt@xxxxxxxxxxx -c dhowells@xxxxxxxxxx -c edumazet@xxxxxxxxxx -c fweisbec@xxxxxxxxx -c oleg@xxxxxxxxxx -s '[PATCH tip/core/rcu 0/N] @@@title@@@'
>
> Then obtain the message-id of the above email, and:
>
> git send-email --in-reply-to="@@@" --no-thread --to linux-kernel@xxxxxxxxxxxxxxx --cc mingo@xxxxxxxxxx --cc jiangshanlai@xxxxxxxxx --cc dipankar@xxxxxxxxxx --cc akpm@xxxxxxxxxxxxxxxxxxxx --cc mathieu.desnoyers@xxxxxxxxxxxx --cc josh@xxxxxxxxxxxxxxxx --cc tglx@xxxxxxxxxxxxx --cc peterz@xxxxxxxxxxxxx --cc rostedt@xxxxxxxxxxx --cc dhowells@xxxxxxxxxx --cc edumazet@xxxxxxxxxx --cc fweisbec@xxxxxxxxx --cc oleg@xxxxxxxxxx /tmp/RCU/*
>
> # git send-email --in-reply-to="@@@" --no-chain-reply-to --to linux-kernel@xxxxxxxxxxxxxxx --cc mingo@xxxxxxxxxx --cc jiangshanlai@xxxxxxxxx --cc dipankar@xxxxxxxxxx --cc akpm@xxxxxxxxxxxxxxxxxxxx --cc mathieu.desnoyers@xxxxxxxxxxxx --cc josh@xxxxxxxxxxxxxxxx --cc tglx@xxxxxxxxxxxxx --cc peterz@xxxxxxxxxxxxx --cc rostedt@xxxxxxxxxxx --cc dhowells@xxxxxxxxxx --cc edumazet@xxxxxxxxxx --cc dvhart@xxxxxxxxxxxxxxx --cc fweisbec@xxxxxxxxx --cc oleg@xxxxxxxxxx --cc bobby.prani@xxxxxxxxx /tmp/RCU/*
> ------------------------------------------------------------------------
>
>> Yubin
>>
>> -----------------------------------------------------------------------
>> >From ae26699b708e3ccb52c134aecf79d64f8e89a23e Mon Sep 17 00:00:00 2001
>> From: Yubin Ruan <ablacktshirt@xxxxxxxxx>
>> Date: Sat, 28 Oct 2017 17:15:06 +0800
>> Subject: [PATCH] locking: a typo fixed
This change is not a simple "typo fix" any more, so I think the commit title
should be reworded to something like "locking: Fix syntactic ambiguity".
And please append my acked-by:
Thanks, Akira
>>
> Suggested-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
Acked-by: Akira Yokosawa <akiyks@xxxxxxxxx>
>> Signed-off-by: Yubin Ruan <ablacktshirt@xxxxxxxxx>
>> ---
>> locking/locking-existence.tex | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/locking/locking-existence.tex b/locking/locking-existence.tex
>> index 9fcbbf9..6340734 100644
>> --- a/locking/locking-existence.tex
>> +++ b/locking/locking-existence.tex
>> @@ -174,8 +174,8 @@ single partitionable data structure such as the hash table shown in the
>> figure, it can be problematic if a given data element can be a member
>> of multiple hash tables or given more-complex data structures such
>> as trees or graphs.
>> -These problems can be solved, in fact, such solutions form the basis
>> -of lock-based software transactional memory
>> +Not only can these problems be solved, but the solutions also form
>> +the basis of lock-based software transactional memory
>> implementations~\cite{Shavit95,DaveDice2006DISC}.
>> However,
>> Chapter~\ref{chp:Deferred Processing}
>> --
>> 2.7.4
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
