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

[Artem Mygaiev <artem.mygaiev@xxxxxxxxxxxxxxx>]

Hi Dario, all

> > [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).

I would suggest to go with "pvdrivers" since we do not stick to just
automotive or embedded
>
> > [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. :-)

Well, we are ready to upstream all the RT-Xen changes to RT-Xen, but
probably it is a good time to start thinking if some stuff out there can
be upstreamed to Xen mainline? Who would be able to drive that?

> 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?

Exactly!

> > [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.

We tend to separate Xen core changes and PV drivers changes. Xen changes
are always posted separately, our intention is to upstream everything
that makes sense to have in the mainline (i.e. no hacks, workarounds,
etc. - that must not leave staging tree)

> 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? :-)

You are absolutely right, but as I wrote above, we would like to suggest
having a staging tree for automotive/embedded stuff.

> 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.

Correct, this is our intention. Also, we dont think that QNX will ever
accept our code :) They are too OSS un-friendly...

> > 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 not many Xen changes, most are not quite related to PV drivers.
But there are things that we need to have (mostly hacks/workarounds) to
support _real_ HW platforms, and we are working on cleaning that stuff
up, but it is not smth that can be done quickly. Nevertheless, we want
community to be able to start playing with it, contribute to code cleanup,
etc. Again, we are asking for the automotive/embedded staging tree.

> > > 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.

Absolutely. We can structure the code in any way, we just need to ensure
it is convenient for community to work with it and there are no subtle
dependencies... Grouping by OS makes sense - there might be some PV drivers
available for one OS and not available for another.

> > > 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.

a) yes, there is a QNX Momentics IDE available for Linux
b) there is an "academic" free license and also 30-day evaluation

> > * 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.

Basically, we would be happy to avoid having a separate repo and make
everything integrated to Linux. But until it is accepted it can live in
"this repo". Framebuffer is already in the Linux so it shall be upstreamed
there...

> > > 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. :-)

Yes, this is what I mean (both).

Best regards,
Artem Mygaiev | AVP - Delivery
GlobalLogic
P +380.44.4929695 ext.2023 M +380.67.9211131 S rosenkrantzguildenstern
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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