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


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

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

Subject: Re: [virtio-dev] Re: [virtio] [PATCH v7 08/11] packed virtqueues: more efficient virtqueue layout

On Mon, 5 Feb 2018 18:00:07 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 05/02/2018 17:57, Halil Pasic wrote:
> >> This is certainly not how we did it for v1.0, and not how
> >> oasis process works generally. Implementations are required
> >> to move to an oasis standard change. We are working on
> >> a committee standard deliverables.
> >>
> >> I don't yet plan to work on an implementation yet: it's a bit of a
> >> chicked and egg problem. People are reluctant to work on what's not in
> >> the spec. We can always make changes as long as there are no
> >> implementations.
> >>  
> > 'We can always make changes as long as there are no implementations'
> > comes very surprising to me. I believed, once a committee specification
> > is released the requirements for changes are given, and don't depend
> > on known implementations.
> > 
> > Does this imply that one should be reluctant about implementing
> > a virtio specification that still has no implementation (because it ain't
> > stable, and may change, because there is no implementation yet)?  
> I agree that this doesn't seem optimal.  This is a much bigger change
> than anything between virtio 0.9 and in virtio 1.0, because it affects
> the data path directly.

Nod. It looks in pretty good shape to me, once we fixed up the things I
noticed during this round, but I still feel a bit uncomfortable without
a prototype for non-pci.

One issue for me is that all work has been done with pci as the
transport, and with a view as to what could be helpful for implementers
of pci cards. There's nothing inherently bad in that, but it does
introduce a chance that other transports may run into problems when
they try to implement it.

Not an insurmountable problem, but something that should be kept in

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