All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the erdma module
@ 2022-01-19 10:15 Bernard Metzler
  2022-01-19 11:31 ` Leon Romanovsky
  0 siblings, 1 reply; 3+ messages in thread
From: Bernard Metzler @ 2022-01-19 10:15 UTC (permalink / raw)
  To: Cheng Xu, jgg, dledford; +Cc: leon, linux-rdma, KaiShen, tonylu



> -----Original Message-----
> From: Cheng Xu <chengyou@linux.alibaba.com>
> Sent: Wednesday, 19 January 2022 05:19
> To: Bernard Metzler <BMT@zurich.ibm.com>; jgg@ziepe.ca;
> dledford@redhat.com
> Cc: leon@kernel.org; linux-rdma@vger.kernel.org;
> KaiShen@linux.alibaba.com; tonylu@linux.alibaba.com
> Subject: [EXTERNAL] Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the
> erdma module
> 
> 
> 
> On 1/18/22 8:53 PM, Bernard Metzler wrote:
> 
> <...>
> 
> >> +static int erdma_res_cb_init(struct erdma_dev *dev)
> >> +{
> >> +	int i;
> >> +
> >> +	for (i = 0; i < ERDMA_RES_CNT; i++) {
> >> +		dev->res_cb[i].next_alloc_idx = 1;
> >> +		spin_lock_init(&dev->res_cb[i].lock);
> >> +		dev->res_cb[i].bitmap = kcalloc(BITS_TO_LONGS(dev-
> >>> res_cb[i].max_cap),
> >> +						sizeof(unsigned long), GFP_KERNEL);
> >
> > better stay with less than 80 chars per line
> > throughout the patch series (I count currently 287 line wraps).
> >
> 
> The kernel now allows 100 chars per line, and the checkpath.pl also
> checks using the new rule now. I will try to change this to 80 chars,
> but it actually makes some code not friendly for reading due to
> indent.
> 

Do we have a recommendation/agreement to stay with 80 chars per line
for the RDMA subsystem? I'd like it, but I am not sure.

> <...>
> 

Thanks,
Bernard.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the erdma module
  2022-01-19 10:15 Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the erdma module Bernard Metzler
@ 2022-01-19 11:31 ` Leon Romanovsky
  2022-01-20  2:51   ` Cheng Xu
  0 siblings, 1 reply; 3+ messages in thread
From: Leon Romanovsky @ 2022-01-19 11:31 UTC (permalink / raw)
  To: Bernard Metzler; +Cc: Cheng Xu, jgg, dledford, linux-rdma, KaiShen, tonylu

On Wed, Jan 19, 2022 at 10:15:43AM +0000, Bernard Metzler wrote:
> 
> 
> > -----Original Message-----
> > From: Cheng Xu <chengyou@linux.alibaba.com>
> > Sent: Wednesday, 19 January 2022 05:19
> > To: Bernard Metzler <BMT@zurich.ibm.com>; jgg@ziepe.ca;
> > dledford@redhat.com
> > Cc: leon@kernel.org; linux-rdma@vger.kernel.org;
> > KaiShen@linux.alibaba.com; tonylu@linux.alibaba.com
> > Subject: [EXTERNAL] Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the
> > erdma module
> > 
> > 
> > 
> > On 1/18/22 8:53 PM, Bernard Metzler wrote:
> > 
> > <...>
> > 
> > >> +static int erdma_res_cb_init(struct erdma_dev *dev)
> > >> +{
> > >> +	int i;
> > >> +
> > >> +	for (i = 0; i < ERDMA_RES_CNT; i++) {
> > >> +		dev->res_cb[i].next_alloc_idx = 1;
> > >> +		spin_lock_init(&dev->res_cb[i].lock);
> > >> +		dev->res_cb[i].bitmap = kcalloc(BITS_TO_LONGS(dev-
> > >>> res_cb[i].max_cap),
> > >> +						sizeof(unsigned long), GFP_KERNEL);
> > >
> > > better stay with less than 80 chars per line
> > > throughout the patch series (I count currently 287 line wraps).
> > >
> > 
> > The kernel now allows 100 chars per line, and the checkpath.pl also
> > checks using the new rule now. I will try to change this to 80 chars,
> > but it actually makes some code not friendly for reading due to
> > indent.
> > 
> 
> Do we have a recommendation/agreement to stay with 80 chars per line
> for the RDMA subsystem? I'd like it, but I am not sure.

Yes, we continue to use old 80 chars limit.

Thanks

> 
> > <...>
> > 
> 
> Thanks,
> Bernard.
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the erdma module
  2022-01-19 11:31 ` Leon Romanovsky
@ 2022-01-20  2:51   ` Cheng Xu
  0 siblings, 0 replies; 3+ messages in thread
From: Cheng Xu @ 2022-01-20  2:51 UTC (permalink / raw)
  To: Leon Romanovsky, Bernard Metzler
  Cc: jgg, dledford, linux-rdma, KaiShen, tonylu



On 1/19/22 7:31 PM, Leon Romanovsky wrote:
> On Wed, Jan 19, 2022 at 10:15:43AM +0000, Bernard Metzler wrote:
>>
>>
>>> -----Original Message-----
>>> From: Cheng Xu <chengyou@linux.alibaba.com>
>>> Sent: Wednesday, 19 January 2022 05:19
>>> To: Bernard Metzler <BMT@zurich.ibm.com>; jgg@ziepe.ca;
>>> dledford@redhat.com
>>> Cc: leon@kernel.org; linux-rdma@vger.kernel.org;
>>> KaiShen@linux.alibaba.com; tonylu@linux.alibaba.com
>>> Subject: [EXTERNAL] Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the
>>> erdma module
>>>
>>>
>>>
>>> On 1/18/22 8:53 PM, Bernard Metzler wrote:
>>>
>>> <...>
>>>
>>>>> +static int erdma_res_cb_init(struct erdma_dev *dev)
>>>>> +{
>>>>> +	int i;
>>>>> +
>>>>> +	for (i = 0; i < ERDMA_RES_CNT; i++) {
>>>>> +		dev->res_cb[i].next_alloc_idx = 1;
>>>>> +		spin_lock_init(&dev->res_cb[i].lock);
>>>>> +		dev->res_cb[i].bitmap = kcalloc(BITS_TO_LONGS(dev-
>>>>>> res_cb[i].max_cap),
>>>>> +						sizeof(unsigned long), GFP_KERNEL);
>>>>
>>>> better stay with less than 80 chars per line
>>>> throughout the patch series (I count currently 287 line wraps).
>>>>
>>>
>>> The kernel now allows 100 chars per line, and the checkpath.pl also
>>> checks using the new rule now. I will try to change this to 80 chars,
>>> but it actually makes some code not friendly for reading due to
>>> indent.
>>>
>>
>> Do we have a recommendation/agreement to stay with 80 chars per line
>> for the RDMA subsystem? I'd like it, but I am not sure.
> 
> Yes, we continue to use old 80 chars limit.
> 
> Thanks
> 

OK, I will follow this rule.

Thanks,
Cheng Xu

>>
>>> <...>
>>>
>>
>> Thanks,
>> Bernard.
>>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-01-20  2:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-19 10:15 Re: [PATCH rdma-next v2 09/11] RDMA/erdma: Add the erdma module Bernard Metzler
2022-01-19 11:31 ` Leon Romanovsky
2022-01-20  2:51   ` Cheng Xu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.