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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

On Wed, Oct 16, 2019 at 4:26 PM Oleksandr Grytsov <al1img@xxxxxxxxx> wrote:
>
> 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.

ping

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