netdev - RE: [RFC PATCH v12 00/17] dlb: introduce DLB device driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CO1PR11MB51700037C8A23B19C0DCF5CAD97C9@CO1PR11MB5170.namprd11.prod.outlook.com>
Date:   Tue, 21 Dec 2021 14:03:38 +0000
From:   "Chen, Mike Ximing" <mike.ximing.chen@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "pierre-louis.bossart@...ux.intel.com" 
        <pierre-louis.bossart@...ux.intel.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>
Subject: RE: [RFC PATCH v12 00/17] dlb: introduce DLB device driver


> -----Original Message-----
> From: Greg KH <gregkh@...uxfoundation.org>
> Sent: Tuesday, December 21, 2021 2:10 AM
> To: Chen, Mike Ximing <mike.ximing.chen@...el.com>
> Cc: linux-kernel@...r.kernel.org; arnd@...db.de; Williams, Dan J <dan.j.williams@...el.com>; pierre-
> louis.bossart@...ux.intel.com; netdev@...r.kernel.org; davem@...emloft.net; kuba@...nel.org
> Subject: Re: [RFC PATCH v12 00/17] dlb: introduce DLB device driver
> 
> On Tue, Dec 21, 2021 at 12:50:30AM -0600, Mike Ximing Chen wrote:
> > v12:
> 
> <snip>
> 
> How is a "RFC" series on version 12?  "RFC" means "I do not think this should be merged, please give me
> some comments on how this is all structured" which I think is not the case here.

Hi Greg,

"RFC" here means exactly what you referred to. As you know we have made many changes since your
last review of the patch set (which was v10).  At this point we are not sure if we are on the right track in
terms of some configfs implementation, and would like some comments from the community. I stated
this in the cover letter before the change log: " This submission is still a work in progress.... , a couple of
issues that we would like to get help and suggestions from reviewers and community". I presented two
issues/questions we are facing, and would like to get comments. 

The code on the other hand are tested and validated on our hardware platforms. I kept the version number
in series (using v12, instead v1) so that reviewers can track the old submissions and have a better
understanding of the patch set's history.

> 
> > - The following coding style changes suggested by Dan will be implemented
> >   in the next revision
> > -- Replace DLB_CSR_RD() and DLB_CSR_WR() with direct ioread32() and
> >    iowrite32() call.
> > -- Remove bitmap wrappers and use linux bitmap functions directly.
> > -- Use trace_event in configfs attribute file update.
> 
> Why submit a patch series that you know will be changed?  Just do the work, don't ask anyone to review
> stuff you know is incorrect, that just wastes our time and ensures that we never want to review it again.
>
Since this is a RFC, and is not for merging or a full review, we though it was OK to log the pending coding
style changes. The patch set was submitted and reviewed by the community before, and there was no
complains on using macros like DLB_CSR_RD(), etc, but we think we can replace them for better
readability of the code.

Thanks
Mike