OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] Re: [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ


On Fri, Jun 9, 2023 at 3:22âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Jun 09, 2023 at 02:27:01PM +0800, Jason Wang wrote:
> > > I would like to keep the stateful interactions of 1.x device outside of 0.9.5.
> >
> > I don't think this is a real problem, but let's see the drawbacks of
> > this proposal:
> >
> > 1) non-trivial changes of full new transport alike ABI
> > 2) can't work for nesting
> > 3) require vendor to implement legacy behaviour which can't be
> > documented precisely
> > 4) require admin virtqueue to work
> >
> > We won't have the above issues if we use modern + legacy header/mac.
> >
> > Thanks
>
>
> All this is true. But it's by design. It makes the legacy thing
> as isolated as possible.

Only the device ABI but not the implementation I think.

> Because let's be frank we won't be
> able to drop legacy support in like 10 years.

Another question is, current modern PCI layout could become "legacy"
in the future. So should then the hardware stick the two legacy
interfaces?

> But hardware
> vendors will do that quickly if they can't sell hardware.

It looks to me that producing a modern only device will be more quick and easy?

Thanks

>
> --
> MST
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]