Re: [RFC] Proposal to address hfi1 UI and EPROM devices

Leon Romanovsky
2016-05-06T04:36:51Z

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

On Thu, May 05, 2016 at 12:08:43PM -0600, 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).

And they are, however the point is a little bit different. There is no
meaning in internal feature implementation without access through
verbs interface.

>
> 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.

Let's close for them PSM and verbs interfaces and see how it is
operable.

>
> Jason

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]