Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT

[Oleksandr Grytsov <al1img@gmail.com>]

On Mon, Oct 28, 2019 at 4:06 PM Oleksandr Grytsov <al1img@gmail.com> wrote:
>
> On Wed, Oct 16, 2019 at 4:26 PM Oleksandr Grytsov <al1img@gmail.com> wrote:
> >
> > On Fri, Oct 11, 2019 at 8:04 PM Ian Jackson <ian.jackson@citrix.com> wrote:
> > >
> > > Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend type VINPUT"):
> > > > On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson <ian.jackson@citrix.com> wrote:
> > > > > I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
> > > > > which introduced what you are calling "user space" backends.  It
> > > > > appears that the vkb backend type enum was introduced there
> > > > > specifically to distinguish between these two situations.  For reasons
> > > > >
> > > > > Am I wrong ?  If not, why is this not working or not suitable ?
> > > >
> > > > You are right. It is not working in some cases due to QEMU_BACKEND macro.
> > > > QEMU_BACKEND treats both backends as QEMU. As result xl performs device
> > > > hotplug on add/remove device. Which is not expected in case "user
> > > > space" backend.
> > >
> > > Then perhaps this macro needs to be adjusted or called only
> > > conditionally or something ?
> >
> > I had an idea to move this macro to libxl__device_type and let device
> > itself decides
> > if it is qemu backend. But in case of VKBD it will read XS to determine backend
> > type. I guess it is ok.
> >
> > >
> > > > In this patch I propose solution similar to VUSB device. Where VUSB
> > > > used for frontend and depends on backend (kernel or QEMU) either
> > > > VUSB or QUSB used for backend device type e.g. use different backend
> > > > device type for different backends.
> > >
> > > I confess I don't quite follow all the VUSB stuff but I don't think it
> > > is necessarily a good model.
> >
> > If you don't mind to move QEMU_BACKEND macrto to libxl__device_type then
> > no need to add new device type at all.
> >
> > >
> > > > Introducing new backend device type for VKBD also allows to have
> > > > both backends (QEMU and non QEMU) run in same domain. Not sure if it
> > > > is useful scenario but with this proposal it is possible from
> > > > technical point of view.
> > >
> > > I don't understand why this is not possible simply by having a
> > > different backend type.
> > >
> > > > > I also don't understand why the "user space" kbd backend seems to be
> > > > > "linux" in the enum.
> > > >
> > > > I agree this is not so good name. But I don't know how to call
> > > > backends which are not running
> > > > inside QEMU in general.
> > >
> > > I think this would be useable on freebsd ?  "linux" definitely seems
> > > wrong.  I see it hasn't been in a release so it is not too late to
> > > rename it, subject to discussion with Juergen as RM.
> > >
> > > > > Where is the implementation of this user space
> > > > > backend ?
> > > >
> > > > We have extended kbd interface (kbdif.h) to support multi-touch events
> > > > as well. And we have
> > > > implemented own kbd backend https://github.com/xen-troops/displ_be/
> > > > It is integrated with display backend as both use wayland API.
> > >
> > > Great.
> > >
> > > > > Is it be controlled entirely through xenstore ?
> > > >
> > > > Yes it is controlled entirely through xenstore: lib xl creates
> > > > frontend/backend entries with
> > > > initial states and configuration.
> > >
> > > And your display backend in "troops" (is that the name of your
> > > project) checks whether the backend type is set to "linux", so that it
> > > knows to ignore ones that say "qemu" ?
> > >
> > > Maybe "linux" should be "troops"...
> > >
> >
> > It doesn't look as generic solution. If some user implements own backend
> > it should add new entry into backend type enum.
> > What about to have just string value instead of enum? In case QEMU
> > we don't have such entry at all but in case custom backend the user
> > can't put any string value here to be recognized by his backend.
> >
> > > Ian.
>
> ping

ping

Ian,

I'm waiting for your comments about following questions:

1. Move QEMU_BACKEND macro to libxl__device_type structure as function
    and let the device to decide it has QEMU backend:

struct libxl__device_type {
    ...
    device_qemu_backend_fn_t qemu_backend
}

In this case, introducing new device type for VKBD is not needed. The VKBD
device will check backend type XS entry to define which backend is running.

2. Use string type for VKBD backend_type field instead of enum. It will be
empty for QEMU and generic for "user space" backends.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel