On 31/10/19 07:57, SAURAV GIREPUNJE wrote:
> On Tue, Oct 29, 2019 at 04:44:23PM +0100, Peter Zijlstra wrote:
>> On Tue, Oct 29, 2019 at 07:12:46PM +0530, SAURAV GIREPUNJE wrote:
>>> On Tue, Oct 29, 2019 at 11:13:00AM +0100, Peter Zijlstra wrote:
>>>> On Tue, Oct 29, 2019 at 03:11:04PM +0530, Saurav Girepunje wrote:
>>>>> Use true/false for bool type "dbg" in mmu.c
>>>>>
>>>>> Signed-off-by: Saurav Girepunje <saurav.girepunje@xxxxxxxxx>
>>>>> ---
>>>>> arch/x86/kvm/mmu.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>>>>> index 24c23c66b226..c0b1df69ce0f 100644
>>>>> --- a/arch/x86/kvm/mmu.c
>>>>> +++ b/arch/x86/kvm/mmu.c
>>>>> @@ -68,7 +68,7 @@ enum {
>>>>> #undef MMU_DEBUG
>>>>>
>>>>> #ifdef MMU_DEBUG
>>>>> -static bool dbg = 0;
>>>>> +static bool dbg = true;
>>>>
>>>> You're actually changing the value from false to true. Please, if you
>>>> don't know C, don't touch things.
>>> Hi,
>>>
>>> Thanks for your review.
>>> I accept that I have given wrong value "true" to debug variable. It's my bad my typo mistake.
>>> I will make sure that I will not touch your exclusive C code where we can assign 0/1 to a bool variable,
>>> As you have given me a free advice, I also request you to please don't review such small patches from newbie to discourage them.
>>
>> I will most certainly review whatever I want, and clearly it is needed.
> Do you want me to discard this patch or resend ?
>
Hi Saurav,
In general I would be happy with replacing 0/1 with false/true, but not
in this particular case. Despite working on KVM for quite some time I
have never found MMU_DEBUG particularly useful, therefore it is going to
go away soon and will be replaced with kernel tracepoints; see for
example commit 335e192a3fa4 ("KVM: x86: add tracepoints around
__direct_map and FNAME(fetch)", 2019-07-05). Therefore, even such a
simple change would be very short lived.
Regarding this patch, I for one am happy that Peter caught the problem
in your patch. His message was perhaps blunt but also honest;
contributing to the kernel requires a very good discipline. I don't
want to discourage you from contributing, but I suggest that you look
into how you developed the patch (from the idea down to sending it) and
figure out how your mistake managed to slip.
Thanks,
Paolo
