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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

On Fri, Oct 11, 2019 at 8:04 PM Ian Jackson <ian.jackson@xxxxxxxxxx> 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@xxxxxxxxxx> 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.

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