From: Rusty Russell <rusty@rustcorp.com.au> To: "Michael S. Tsirkin" <mst@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, virtualization@lists.linux-foundation.org, netdev <netdev@vger.kernel.org> Subject: Re: Rusty away 18th September -- 11th October Date: Wed, 17 Sep 2014 01:23:46 +0930 [thread overview] Message-ID: <87a95zfto5.fsf@rustcorp.com.au> (raw) In-Reply-To: <20140914062116.GA23868@redhat.com> "Michael S. Tsirkin" <mst@redhat.com> writes: > On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst@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.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au> To: "Michael S. Tsirkin" <mst@redhat.com> Cc: netdev <netdev@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, virtualization@lists.linux-foundation.org Subject: Re: Rusty away 18th September -- 11th October Date: Wed, 17 Sep 2014 01:23:46 +0930 [thread overview] Message-ID: <87a95zfto5.fsf@rustcorp.com.au> (raw) In-Reply-To: <20140914062116.GA23868@redhat.com> "Michael S. Tsirkin" <mst@redhat.com> writes: > On Fri, Sep 12, 2014 at 10:58:03AM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst@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.
next prev parent reply other threads:[~2014-09-16 15:54 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-11 0:56 Rusty away 18th September -- 11th October Rusty Russell 2014-09-11 0:56 ` Rusty Russell 2014-09-11 11:43 ` Michael S. Tsirkin 2014-09-11 11:43 ` Michael S. Tsirkin 2014-09-12 1:28 ` Rusty Russell 2014-09-12 1:28 ` Rusty Russell 2014-09-14 6:21 ` Michael S. Tsirkin 2014-09-14 6:21 ` Michael S. Tsirkin 2014-09-16 15:53 ` Rusty Russell [this message] 2014-09-16 15:53 ` Rusty Russell 2014-09-16 16:20 ` Michael S. Tsirkin 2014-09-16 16:20 ` Michael S. Tsirkin 2014-09-11 20:16 ` Linus Torvalds 2014-09-11 20:16 ` Linus Torvalds
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87a95zfto5.fsf@rustcorp.com.au \ --to=rusty@rustcorp.com.au \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.