On 05/05/2016 02:08 PM, Jason Gunthorpe wrote:
> On Thu, May 05, 2016 at 03:39:32PM +0300, Leon Romanovsky wrote:
>
>>> I think the message really should be that if your driver contains uAPI
>>> changes those should be in separate patches that are clearly identified. So
>>> if you have a driver that is developed off-list initially, instead of just
>>> breaking it up into chunks for submission add another step.
>>>
>>> Something like this:
>>> 1) Submit patch series which break-ups internally developed code
>>> 2) Submit patch series with separated out uAPI code
>>> 3) Submit patch that makes the build go-live
>
> Yes. Perhaps even submit #2 after getting #1 mainlined.
>
> Make it easy to find the important/controversial things and the review
> process will work much better for everyone. Buring stuff in a monster
> patch is just going to stretch it out.
>
>>> These can all be submitted together, but with the patches broken up like
>>> this reviewers can target uAPI code more easily.
>
>> At the end, there is no point of accepting (1) without finished review
>> of (2 and 3). Right now all patch series already have such internal separation
>> in a slightly different order.
>
> Eh?
>
> Drivers should be able to stand alone without dedicated uapis
> (excluding the udata stuff).
That's probably true most of the time...
> For instance, the HFI1 driver is as functional as any other RDMA
> driver without it's cdev, eeprom, debug and sysfs uAPIs. Those are all
> value add features that do not impact the driver's ability to operate
> as an RDMA device.
In this case though, not so much. The qib and hfi1 devices have always
been PSM devices first, verbs devices merely as a compat layer. It's
easier to provides a verbs interface for kernel ULPs than it is to write
PSM in the kernel. But their hardware is designed around the way PSM
uses it, and how verbs makes use of it is decidedly sub-optimal. They
could do without the eeprom, debug, and sysfs stuff, but the cdev and
PSM not so much.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
