Re: Changing user-mode interfaces

[Owen Smith <owen.smith@xxxxxxxxxx>]

If xencontrol.dll is deemed the public stable interface then;

- xeniface.inf needs to include xencontrol.dll (its missing at the moment, trivial fix)

- xenagent should be modified to use xencontrol.dll calls

- xencontrol.dll could be extended to handle RegisterDeviceNotification events and/or expose the raw device handle

- XenServer's usages would need to reference xencontrol.dll interfaces (its possible, via LoadLibrary/GetProcAddress, but not pretty)

Owen

On Thu, Nov 30, 2023 at 2:22 PM Paul Durrant <xadimgnik@xxxxxxxxx> wrote:

On 30/11/2023 13:34, Owen Smith wrote:
> XenAgent in the XenIface package currently uses the IOCTLs directly -
> this shouldnt be too difficult to rewrite to be managed by xencontrol,
> other than the RegisterDeviceNotification calls on the device handle (to
> detect xeniface removal)
>

That one's not a concern because it is in the same package as the DLL.

> XenServer's management agent uses the IOCTLs directly (via C# PInvoke)
> in a similar manner. The additional problem here would be requiring
> DllImport from a file not supplied with the agent binaries would make
> distribution difficult, especially via Windows Update.
>
> In the short term, XenServer does not use the Gnttab IOCTLs or
> xencontrol.dll, so any changes to this set of IOCTLs will not affect us
> directly.
> In general, I'm opposed to changing IOCTL definitions, as it can easily
> break when using a package based distribution (i.e. it's impossible to
> guarantee all components, like xeniface and an agent, are kept in sync
> and binary compatible). Adding IOCTLs to resolve the RequestID changes
> shouldnt be an issue.
>

It depends what we class as stable.

Alos, why would there be a distribution issue if using the DLL. The fact
that XenServer's agent uses the IOCTLs directly means it must already
depend on the XENIFACE packages... and that also delivers the DLL,
doesn't it?

   Paul