[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01b221f3-d923-1abb-0168-bfeba80b9a9a@infradead.org>
Date: Mon, 23 Jul 2018 14:44:28 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Mark Railton <mark@...krailton.com>
Cc: boris.ostrovsky@...cle.com, jgross@...e.com,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
On 07/23/2018 02:40 PM, Mark Railton wrote:
> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
>> On 07/23/2018 02:34 PM, Mark Railton wrote:
>>> Fixed issue with multi line comment
>>
>> Fix [not Fixed]
>>
>>>
>>> Signed-off-by: Mark Railton <mark@...krailton.com>
>>> ---
>>> drivers/xen/xlate_mmu.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>> index 23f1387b3ef7..3b03bc1641ed 100644
>>> --- a/drivers/xen/xlate_mmu.c
>>> +++ b/drivers/xen/xlate_mmu.c
>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>>> struct remap_data data;
>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>>>
>>> - /* Kept here for the purpose of making sure code doesn't break
>>> - x86 PVOPS */
>>> + /* Kept here for the purpose of making sure code doesn't
>>> + * break x86 PVOPS
>>> + */
>>
>> That is still not the preferred kernel multi-line comment style.
>> Documentation/process/coding-style.rst says:
>>
>> /*
>> * This is the preferred style for multi-line
>> * comments in the Linux kernel source code.
>> * Please use it consistently.
>> *
>> * Description: A column of asterisks on the left side,
>> * with beginning and ending almost-blank lines.
>> */
>>
>> although Networking code has a slightly different preferred style (as in
>> your patch).
>>
>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>>>
>>> data.fgfn = gfn;
>>>
>>
>>
>> --
>> ~Randy
>
> Thank's for the feedback, I'll get that updated now.
>
> I'm still kinda new to this, I assume I need to send the new patch via
> git send-email?
That is one option. Use whatever works for you.
There are several email clients that also work well.
See Documentation/process/email-clients.rst.
--
~Randy
Powered by blists - more mailing lists