Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On mer, 2014-06-04 at 15:22 +0100, Lars Kurth wrote:
> Artem, Xen community,
> 
Hi everyone,

> There is a separate discussion for a few personal repos on xenbits,
> which is waiting for some information. But does not require a
> community discussion.
> 
> == important ==
> I marked items, which require community input as [need input] below.
> Based on discussion and feedback, I would suggest to create a
> subproject proposal or otherwise.
> 
I like the idea of the subproject too. More details below.

> On 04/06/2014 14:04, Artem Mygaiev wrote:
> 
> > As a part of effort on bringing Xen into Automotive (and thus Embedded)
> > space, we are working on a set of PV drivers needed to share
> > peripherals between domains.
> >  * PV audio - new driver using ALSA
> >  * PV USB - based on old existing PV USB solution
> >  * PV framebuffer - modifications and improvements for existing FB
> >  * PV events - new driver for sharing HIDs across domains (touchscreen,
> >    keyb, etc.)
> So just to clarify. The proposal here is to create another top-level
> git *.git tree alongside xen.git 
> @Artem, @Andrii
> 
> That raises a number of questions:
> 
> [need input] What name? posibilities are "automotive-pvdrivers,
> "embedded-pvdrivers", "pvdrivers", ...
> 
IMHO, something like 'embedded-pvdrivers', i.e., a little bit more
generic than _automotive_-xxx, is better. Perhaps we can have something
even more generic, like 'pvdrivers' or 'additional-pvdrivers' and, if
necessary, have branches there (e.g., an automotive branch).

Let's hear @Artem and @Andrii, though, as I think their opinion, as the
main contributors (at least for now) for this repo, is quite
important. :-)

> [need input] Taking a slightly wider view, I know there was some
> discussion related to upstreaming RT-Xen. How does this fit in? Would
> there maybe be a case for "embedded/pvdrivers",
> "embedded/schedulers", ... 
> 
Not really, IMO. The idea there is not to "upstream RT-Xen". It is,
OTOH, "extract the best from RT-Xen and upstream that properly, as _the_
real-time scheduling solution for Xen".
Of course, contributions from all the others that have been working on
Real-Time scheduling on Xen are also welcome, but the point is that we
do want a working RT scheduling solution (replacing SEDF, which is not
functional any longer), and we want it upstream, not in a branch, in a
subproject, or anywhere else. :-)

This approach, I think, applies to most of the Xen components of
Globalogic's work. I mean, as usual, the goal should be to upstream
*everything*, unless there is something that can't live upstream for
some good reason... Is that the case?

> [need input] Should these be owned by a separate subproject or
> attached to an existing subproject (e.g. the Hypervisor project)
> 
So, I may be very wrong and/or missing something but I think we should
distinguish between what code/changes are required in Xen and what
outside from it.

It would, probably, be useful to have a more clear view of that. What
I'm thinking is, for each one of these new drivers, what are the
modifications required in Xen, and what instead lives in the various
OSes? Since we're talking about backends and frontends, I expect the
latter for most of the code.

I'm saying/asking this because, if the latter is the case, there seems
to be no need for any alternative xen.git, mirroring Xen's code or
anything. As said above, if something has to change in Xen, that should
go through upstream.
Probably, personal branches on xenbits for a few Globalogic contributors
could help the upstreaming process, in which case I hope they can get
them, but nothing more than that... Or, perhaps, I am missing or
misreading something badly? :-)

This lead us to where the actual code of the frontends and backends
--i.e., the component _outside_ Xen-- should live. In the best possible
world, the answer would be upstream Linux, upstream QNX, etc. However
(although I think that should be the long term goal), I appreciate that
such thing can take a while to actually happen. In the meanwhile, it
would be great to have the code somewhere, so that people can download
it, compile it, and run it in their Dom0 and guest of choice. For this,
I totally see how a (sub)project repo (the 'pvdrivers' repo we were
talking about above) can help.

> My personal view is that we should not create any offical new Xen
> Project codebases outside a subproject. Otherwise we will run into
> problems at some point. 
>
Indeed.

> Do note, that this is a case we have not been through: 
> * in the case of Xen on ARM the project goal was to upstream changes
> to the hypervisor (we created a subproject to inbcrease visibility)
> * Mirage OS was clearly a separate codebase and project already
> 
As said, I'm not sure how much this case is different. @Artem? Is the
situation (almost) as black-and-white as I see it? Or are there a lot of
Xen changes required for your fe/be to actually work? If there are a lot
of Xen changes required, how 'upstreamable' (do you think) are they?

> There are trade-offs to either decision
> * The key benefits of a separate subproject are commit access and
> project leadership for GlobalLogic. And consequently less burden on
> the existing Xen Project committer base. 
>
The fe and be code and repo should definitely be owned --and the
development led-- by Globalogic... They're doing a great job at that in
any case already, so... :-P :-P

> * Improved visibility and PR value : this would be beneficial for a
> new subproject as well as the Xen Project as a whole. It would show
> increased momentum for the Xen project overall, while keeping the
> message to the market clear.
>
Agreed.

> > This list is not final, other things are to be added later on. Each
> > driver consists, obviously, of frontend and backend which may be
> > implemented for different OSes. So far only Linux is supported, QNX is
> > wip, ArcCore or similar being considered. Due to this, each driver has
> > following structure (sample):
> > /pv_audio
> >   /linux-alsa-be
> >   /linux-fe
> >   /qnx-be
> >   /qnx-fe
> [need input] I suppose the long-term question here is whether
> "pvdrivers/pvaudio/*" or "pvdrivers/qnx/pvaudio/*" is better in the
> long run. Part of it comes down to any headers and other stuff is
> needed to build drivers for the like of "qnx". Cutting components by
> OS, aka "pvdrivers/qnx/*", ... may also be cleaner from a licensing
> and ownership perspective (e.g. say another OS is added by a company
> called "foobar")
> 
Well, even from a "user" perspective, I think the clearer the indication
of which code one should checkout/download for a specific OS, the
better...

I mean, if I want to run Linux as Dom0 and QNX as DomU, I don't need QNX
backends, and I'd be happy to be able not to download/build them.

> > QNX and other OSes
> > will have licenses that are required by corresponding regulations, some
> > may be not open nevertheless we tend to make all parts of the code
> > available to the Xen community.
> Artem, Andrii: Just to clarify 
> * Can QNX drivers be built a) on Linux and b) without requiring to
> purchase QNX
> * Are there any issues with QNX driver headers : in other words, can
> these be included under OSI approved licenses ?
>
I agree this is one interesting bit to know.

> * I suppose there is also some unclarity about which Linux drivers
> would live in Linux (and which in this repo). Can we try and establish
> a more concrete list?
> 
Agreed.

> > As a starting point in publishing the code we would like to request for
> > creation of a dedicated project where these drivers could be maintained
> > by us (GlobalLogic) and available to the community for use, and
> > hopefully, further development.
> Artem, Andrii: Just to clarify 
> * short term: did you mean the personal branches we already discussed?
> * and longer term: conclude this discussion such that we can find an
> official home for those drivers
> 
I think both could be useful, in the sense that I tried to outline in
this email.... I hope I've made myself clear enough. :-)

Thanks (particularly to Artem for starting this) and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel