"Michael S. Tsirkin" <mst at redhat.com> writes:> On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: >> Hi all, >> >> Probably won't read mail. Linus, I'll have pull requests early >> next week; if there's anything needed I'm sure Michael Tsirkin can >> handle it. > > Sure. > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > I started working on them based on your virtio-pci-new-layout branch. > > If ready before the merge window, are you ok with me merging this > support (without you having the opportunity to review first)?Sorry, absolutely not. I *really* want to review this in depth; if we make a mistake, it's going to hurt us significantly. And until we have the qemu bits ready, it's really hard to tell if we've got this right. So I'd rather delay and make sure we're solid. Thanks, Rusty.
On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote:> "Michael S. Tsirkin" <mst at redhat.com> writes: > > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: > >> Hi all, > >> > >> Probably won't read mail. Linus, I'll have pull requests early > >> next week; if there's anything needed I'm sure Michael Tsirkin can > >> handle it. > > > > Sure. > > Rusty, there's a small chance virtio 1.0 bits will be ready in time. > > I started working on them based on your virtio-pci-new-layout branch. > > > > If ready before the merge window, are you ok with me merging this > > support (without you having the opportunity to review first)? > > Sorry, absolutely not. I *really* want to review this in depth; if we > make a mistake, it's going to hurt us significantly.Right but it's only a merge window - we can fix bugs and even disable the new driver afterwards, can't we?> And until we have the qemu bits ready, it's really hard to tell if we've > got this right.Sure, I meant if qemu bits are ready too, and if things work together. It wouldn't do to merge a driver that isn't ready.> So I'd rather delay and make sure we're solid. > > Thanks, > Rusty.Something else we can do, is refactoring that splits driver out to common and legacy bits, and changes APIs. No? -- MSt
"Michael S. Tsirkin" <mst at redhat.com> writes:> On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst at redhat.com> writes: >> > On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote: >> >> Hi all, >> >> >> >> Probably won't read mail. Linus, I'll have pull requests early >> >> next week; if there's anything needed I'm sure Michael Tsirkin can >> >> handle it. >> > >> > Sure. >> > Rusty, there's a small chance virtio 1.0 bits will be ready in time. >> > I started working on them based on your virtio-pci-new-layout branch. >> > >> > If ready before the merge window, are you ok with me merging this >> > support (without you having the opportunity to review first)? >> >> Sorry, absolutely not. I *really* want to review this in depth; if we >> make a mistake, it's going to hurt us significantly. > > Right but it's only a merge window - we can fix bugs and even disable > the new driver afterwards, can't we?Yes, but if we get something wrong we have to live with it. We made that mistake with virtio-pci the first time around... It isn't enough that the code 'works', it has to match the spec. And that requires careful thought and review.>> And until we have the qemu bits ready, it's really hard to tell if we've >> got this right. > > Sure, I meant if qemu bits are ready too, and if things work together. > It wouldn't do to merge a driver that isn't ready. > > >> So I'd rather delay and make sure we're solid. >> >> Thanks, >> Rusty. > > Something else we can do, is refactoring that splits driver > out to common and legacy bits, and changes APIs. > No?Yes, for sure. But there's no hurry to get those into the merge window. Cheers, Rusty.