Messages in this thread | | | Subject | Re: [PATCH v3 01/18] nitro_enclaves: Add ioctl interface definition | From | "Paraschiv, Andra-Irina" <> | Date | Fri, 5 Jun 2020 18:39:15 +0300 |
| |
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.
| |