Re: Changing user-mode interfaces

[Owen Smith <owen.smith@xxxxxxxxxx>]

At XenServer we dont use the xencontrol.dll interface, but do use the IOCTLs directly. I'd prefer to keep the IOCTL parameters fixed for each particular IOCTL, but adding new IOCTLs should be fine (IIRC, there are 'gaps' in the numbering between different codes to facilitate this).

Owen

On Tue, Nov 28, 2023 at 10:40 AM Rafał Wojdyła <omeg@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Hello,

What is the policy on potentially breaking changes in the user-mode
interface? I have some additions to the gnttab IOCTL (sharing already
existing memory in addition to driver-allocated one) which require
changing the xencontrol interface or adding another version similar to
how the driver interfaces work.

Additionally I'd like to change how the bookkeeping of gnttab user
requests is done: currently each IOCTL contains a process-unique ID as a
part of the input. This ID is managed by xencontrol and that can lead to
bugs if a process opens more than one xencontrol handle (IDs will be
duplicated, the driver checks for that but the requests will fail).

I think I was the one who wrote that code in the first place (it has
been some time... ;), but it seems like we can just remove the request
IDs and xeniface would track gnttab requests by the user-mode address of
the shared memory (per-process of course). I don't think it's possible
to share the same region twice so that should be fine?

So since the "new" IOCTL parameters would get rid of the ID parameter
(and introduce optional address parameter for memory sharing) I'm
wondering what's the best way to do the change -- introducing a new
version is probably the safest, but it would be a bit messy. I wonder
who else besides us (ITL) even uses this code... :)

Anyway, what's your thoughts on this?

--
Rafał Wojdyła
Invisible Things Lab