From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [Need Input] (informal) Automotive PV drivers subproject request Date: Thu, 5 Jun 2014 15:32:54 +0200 Message-ID: <1401975174.31414.34.camel@Solace> References: <538F2BA7.8060806@xen.org> <1401899758.6866.44.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2397899678062243434==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Artem Mygaiev Cc: Andrii Tseglytskyi , Lars Kurth , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============2397899678062243434== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+yxyJPI7di9yPBWX0FhH" --=-+yxyJPI7di9yPBWX0FhH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote: > Hi Dario, all >=20 Hey! > > 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). >=20 > I would suggest to go with "pvdrivers" since we do not stick to just > automotive or embedded > Right. > 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? > It is indeed. > Who would be able to drive that? >=20 Work is already ongoing. A bunch of people are working on making this happen, and I'm (doing my best at) coordinating such efforts. :-) > > 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. >=20 > 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) >=20 Oh, I see. So, ideally, it's how I said: all Xen changes upstream. In practice, however, that is a bit tricky. I actually appreciate that this is the case. I'd be tempted to ask what kind of hacks, how big, how intrusive, etc, but I don't want to get into too many details in this thread. It looks like we do need a mirror/copy/whatever of the Xen git tree, then. This leaves open Lars' question of where it should live. Personally, I don't think it would be terrible to have a full fledged and shiny subproject for the additional pvdrivers, and have the 'hacked Xen' repo be someone's personal development tree (once a bunch of you guys get repositories on xenbits)... After all, in a wiki page with all the instructions on how to checkout and build everything, all one needs is some place where to point `git clone ...', isn't it? Anyway... Let's see what others think... > > 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. >=20 > Correct, this is our intention. Also, we dont think that QNX will ever > accept our code :) They are too OSS un-friendly... >=20 Yep, I've got some experience with that beast :-/ > > I mean, if I want to run Linux as Dom0 and QNX as DomU, I don't need QN= X > > backends, and I'd be happy to be able not to download/build them. >=20 > 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 drive= rs > available for one OS and not available for another. >=20 Indeed. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-+yxyJPI7di9yPBWX0FhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOQcZgACgkQk4XaBE3IOsSNqwCeKIlwEHctz2dkY6yxXcgN9ZeP VVMAoKzzVVN6tjK7/CT/KZGQ2rSVtG1M =JEtK -----END PGP SIGNATURE----- --=-+yxyJPI7di9yPBWX0FhH-- --===============2397899678062243434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2397899678062243434==--