From: Wei Liu <wei.liu2@citrix.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
Oleksandr_Andrushchenko@epam.com,
Oleksandr Andrushchenko <andr2000@gmail.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: Xen 4.9 Development Update
Date: Thu, 26 Jan 2017 17:06:13 +0000 [thread overview]
Message-ID: <20170126170613.7ldpafz6ak6bptvy@citrix.com> (raw)
In-Reply-To: <bdda865f-23dd-3eb5-741a-da342cf15ad8@arm.com>
On Thu, Jan 26, 2017 at 12:27:15PM +0000, Julien Grall wrote:
> Hi,
>
> On 09/12/2016 19:09, Andrew Cooper wrote:
> > On 09/12/16 19:01, Stefano Stabellini wrote:
> > > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
> > > > On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> > > > > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> > > > > > > > Should we have a section on new PV drivers? If so, I suggest to add:
> > > > > > > > - Xen transport for 9pfs
> > > > > > > > - PV Calls
> > > > > > > Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> > > > > > >
> > > > > > This is a great idea. Let me explain what we have and what the direction
> > > > > > is:
> > > > > > 1. Frontends which we already have, working, but need to refactor/cleanup:
> > > > > > 1.1. PV sound
> > > > > > 1.2. PV DRM
> > > > > > 1.3. DISPL protocol, I will push v1 for review right after sndif done
> > > > > > 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
> > > > > > via DRM Prime buffer sharing)
> > > > > > 1.4. PV events not done, but we are considering [1]. If it fits and
> > > > > > is maintained,
> > > > > > then we'll probably stick to it, otherwise new PV will be created
> > > > > >
> > > > > > 2. Backends, for the above frontends already implemented:
> > > > > > 2.1. A unified library for Xen backends (libxenbe)
> > > > > > 2.2. DRM + Wayland
> > > > > > 2.3. ALSA
> > > > > > 2.4. Events not implemented yet
> > > > > >
> > > > > > All the above sources are available on *public* Github repos
> > > > > > (I can provide links on request) and the intention is to
> > > > > > upstream.
> > > > > >
> > > > > Please do post the links..
> > > > Please note these are all WIP:
> > > > 1. Frontends
> > > > https://github.com/andr2000?tab=repositories
> > > > 2. Backends
> > > > https://github.com/al1img?tab=repositories
> > > Now, I don't want to sound pessimistic, but I thought I was being
> > > audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
> > > think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
> > > PV DRM frontends and backends, all by April? I would probably reduce the
> > > list a bit.
> >
> > I think it would be good to main two lists. One of "the stuff people
> > are working on overall", and "the subset of it intended/expected for the
> > forthcoming release".
> >
> > Stuff will invariably slip, but even if the work isn't intended for the
> > forthcoming release, it it still useful to see if anyone in the
> > community is working on a related topic.
>
> I am thinking to re-introduce the state of a series (none, fair, ok, good,
> done) as it was done in the past [1].
>
> "The states are: none -> fair -> ok -> good -> done
>
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs"
>
We (I?) ditched them because they weren't that useful. "None" is just
signalling of intent, which doesn't carry enough of meaningful
information. "Fair", "ok" and "good" are all subjective -- we've seen
"good" series slipped due to last minute issues.
If we really want status, I would suggest more concrete status:
design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed
These are more tangible and objective.
> Also, rather than having two separate lists as you suggested, I would
> combine the two and differentiate the items planned for next release with a
> tag (let's say [next]).
>
No opinion on this.
Wei.
> Any opinions?
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01816.html
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-01-26 17:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 15:12 Xen 4.9 Development Update Julien Grall
2016-12-08 22:00 ` Stefano Stabellini
2016-12-09 10:18 ` Julien Grall
2016-12-09 12:57 ` Oleksandr Andrushchenko
2016-12-09 13:57 ` Pasi Kärkkäinen
2016-12-09 14:10 ` Oleksandr Andrushchenko
2016-12-09 19:01 ` Stefano Stabellini
2016-12-09 19:09 ` Andrew Cooper
2017-01-26 12:27 ` Julien Grall
2017-01-26 17:06 ` Wei Liu [this message]
2017-01-30 15:32 ` Julien Grall
2017-01-30 15:45 ` Wei Liu
2017-02-08 17:53 ` Julien Grall
2016-12-14 13:45 ` Artem Mygaiev
[not found] <E1cF0Mx-0005da-Th@lists.xenproject.org>
2016-12-08 15:20 ` Jan Beulich
2016-12-08 15:36 ` Wei Liu
2016-12-08 15:57 ` Jan Beulich
2016-12-08 16:00 ` Wei Liu
-- strict thread matches above, loose matches on Subject: below --
2017-01-30 15:33 Julien Grall
[not found] <4c6084d167e041db9bc35dabe1e68c15@LASPEX02CAS01.citrite.net>
2017-01-30 16:21 ` Wei Liu
[not found] <E1cYDxP-0001LM-H5@lists.xenproject.org>
2017-01-31 13:51 ` Oleksandr Andrushchenko
2017-02-08 18:03 ` Julien Grall
2017-02-08 18:17 ` Konrad Rzeszutek Wilk
2017-02-08 18:56 ` Oleksandr Andrushchenko
2017-02-08 19:29 ` Julien Grall
2017-02-08 19:42 ` Oleksandr Andrushchenko
2017-02-08 19:27 ` Julien Grall
2017-02-08 18:59 ` Tamas K Lengyel
2017-02-15 21:40 ` Sergej Proskurin
2017-02-20 7:22 ` Haozhong Zhang
2017-03-28 14:20 Julien Grall
[not found] <E1csryw-0002dr-7q@lists.xenproject.org>
2017-03-30 18:24 ` Oleksandr Tyshchenko
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=20170126170613.7ldpafz6ak6bptvy@citrix.com \
--to=wei.liu2@citrix.com \
--cc=Oleksandr_Andrushchenko@epam.com \
--cc=andr2000@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).