[Ofvwg] Further thoughts on uAPI

[Hefty, Sean]

> ** And to answer my own question: there is actually a good reason to
>    continue the 'common' API - internally the uverbs/drivers use the
>    kAPI to do most of the work. An incremental API transformation
>    requires us to continue to provide that basic flow or face a
>    daunting task of radically upgrading every single driver!

I could not make the ofvwg call this week, so I missed this conversation.  But I agree that we can't have radical driver upgrades.


> Your observation that uAPI users don't need the kapi struct ib_qp is
> along the same lines and very valid. Could the driver build a more
> efficient struct?

I would add that there are efficiencies that we can gain if we support higher level of abstractions.  For example, there's no technical reason why connection establishment couldn't be done entirely in the kernel, versus making multiple user to kernel transitions to modify the qp.  And this would provide additional security that the app doesn't modify the path record.


> I'm guessing some hybrid is going to be best, eg simple objects like a
> verbs PD could be handled through common code calling the kAPI for all
> drivers and complex very driver-specific objects like MRs, AHs or QPs
> are better routed directly to the driver without using the kapi.

I agree, and I think this may fall out naturally.


> I'm also very concerned to give driver authors a 'free reign' to
> design their driver-specific uAPIs, because historically it has been
> proven across the kernel that driver authors do a bad job of that kind
> of work :( Thus encouraging drivers to stick with the #1 approach as
> much as possible should be encouraged, and all examples of #2 has to
> be reviewed by the core maintainer group (eg to ensure someone doesn't
> try to access EEPROM over this interface :P )

I agree here too.  The main criticism I've read against ioctl's is that they allowed drivers to implement poorly designed interfaces.  Trying to fix that by using write didn't really address the issue...


> We already have to maintain it exactly as is (with write) for a long
> time, adding another copy that is ioctl based and has to live forever
> doesn't seem great :( Maybe the compromise is to use this scheme to
> carry the existing struct as the base attribute?

I was assuming that the write uABI would be replaced with the ioctl path, so I was looking at a way to minimize that transition.  If that's not necessary, I'm sure I could come up with all sorts of other ideas.  :)

It's taking me longer to work through the ioctl details because of, let's call it, significant work distractions.  But I'll comment on your proposals separately once I analyze them more.

- Sean