From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
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: Tue, 16 Sep 2014 19:20:55 +0300 [thread overview]
Message-ID: <20140916162055.GB2437@redhat.com> (raw)
In-Reply-To: <87a95zfto5.fsf@rustcorp.com.au>
On Wed, Sep 17, 2014 at 01:23:46AM +0930, Rusty Russell wrote:
> "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.
Well my point was if we do put them into the merge window,
just adding a new driver will be easy and is often allowed
pretty late in the cycle.
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
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: Tue, 16 Sep 2014 19:20:55 +0300 [thread overview]
Message-ID: <20140916162055.GB2437@redhat.com> (raw)
In-Reply-To: <87a95zfto5.fsf@rustcorp.com.au>
On Wed, Sep 17, 2014 at 01:23:46AM +0930, Rusty Russell wrote:
> "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.
Well my point was if we do put them into the merge window,
just adding a new driver will be easy and is often allowed
pretty late in the cycle.
--
MST
next prev parent reply other threads:[~2014-09-16 16:17 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
2014-09-16 15:53 ` Rusty Russell
2014-09-16 16:20 ` Michael S. Tsirkin [this message]
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=20140916162055.GB2437@redhat.com \
--to=mst@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--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: link
Be 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.