On 05/06/2020 11:15, Stefan Hajnoczi wrote:
On Mon, Jun 01, 2020 at 10:20:18AM +0300, Paraschiv, Andra-Irina wrote:
On 01/06/2020 06:02, Benjamin Herrenschmidt wrote:
On Wed, 2020-05-27 at 09:49 +0100, Stefan Hajnoczi wrote:
What about feature bits or a API version number field? If you add
features to the NE driver, how will userspace detect them?
Even if you intend to always compile userspace against the exact kernel
headers that the program will run on, it can still be useful to have an
API version for informational purposes and to easily prevent user
errors (running a new userspace binary on an old kernel where the API is
different).
Finally, reserved struct fields may come in handy in the future. That
way userspace and the kernel don't need to explicitly handle multiple
struct sizes.
Beware, Greg might disagree :)
That said, yes, at least a way to query the API version would be
useful.
I see there are several thoughts with regard to extensions possibilities. :)
I added an ioctl for getting the API version, we have now a way to query
that info. Also, I updated the sample in this patch series to check for the
API version.
Great. The ideas are orthogonal and not all of them need to be used
together. As long as their is a way of extending the API cleanly in the
future then extensions can be made without breaking userspace.
Agree, as we achieve the ultimate goal of having a stable interface,
open for extensions without breaking changes.
Thanks,
Andra
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
