Displaying 4 results from an estimated 4 matches for "modern_featur".
Did you mean:
modern_features
2014 Nov 27
4
[PATCH RFC v4 00/16] qemu: towards virtio-1 host support
On Thu, 27 Nov 2014 18:18:25 +0200
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
> > So we should have a per-device callback into the transport layer, say
> > check_legacy()?
>
> I would just have 2 masks: legacy_features and features.
But these belong to the device type and the transport
2014 Nov 27
4
[PATCH RFC v4 00/16] qemu: towards virtio-1 host support
On Thu, 27 Nov 2014 18:18:25 +0200
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
> > So we should have a per-device callback into the transport layer, say
> > check_legacy()?
>
> I would just have 2 masks: legacy_features and features.
But these belong to the device type and the transport
2014 Nov 27
0
[PATCH RFC v4 00/16] qemu: towards virtio-1 host support
...gt; legacy-only.
> >
> > I dislike callbacks. Let's just give all info to core,
> > and have it DTRT.
> >
> Have a is_legacy flag in the vdev that is initialized to 1, and
> transports can unset it when the revision is negotiated or during init?
I would say have modern_features, legacy_features, and set host_features
correctly.
--
MST
2014 Nov 27
0
[PATCH RFC v4 00/16] qemu: towards virtio-1 host support
...gt; legacy-only.
> >
> > I dislike callbacks. Let's just give all info to core,
> > and have it DTRT.
> >
> Have a is_legacy flag in the vdev that is initialized to 1, and
> transports can unset it when the revision is negotiated or during init?
I would say have modern_features, legacy_features, and set host_features
correctly.
--
MST