* Automotive PV drivers project request @ 2014-06-04 13:04 Artem Mygaiev 2014-06-04 14:22 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Artem Mygaiev @ 2014-06-04 13:04 UTC (permalink / raw) To: xen-devel 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.) 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 Linux kernel code is developed under GPLv2 license, userspace components like some backends are under Apache 2 license, so can be integrated into software with commercial licenses. 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. 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 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-04 13:04 Automotive PV drivers project request Artem Mygaiev @ 2014-06-04 14:22 ` Lars Kurth 2014-06-04 16:35 ` Dario Faggioli 2014-06-04 14:36 ` Automotive PV drivers project request Roger Pau Monné 2014-06-05 13:17 ` Automotive PV drivers project request David Vrabel 2 siblings, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-04 14:22 UTC (permalink / raw) To: Artem Mygaiev, xen-devel, Andrii Tseglytskyi [-- Attachment #1.1: Type: text/plain, Size: 5616 bytes --] Artem, Xen community, based on prior discussion with Artem and the session at the Hackathon I asked Artem to outline a pre-cursor for a proposal for a new offical Xen Project git repo and frame the question whether we should associate it to the Hypervisor subproject or whether we should propose a new subproject. This is really the context of this mail. Also see, http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg00289.html for the Hackathon minutes 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. 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", ... [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", ... [need input] Should these be owned by a separate subproject or attached to an existing subproject (e.g. the Hypervisor project) 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. 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 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. * 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. * A subproject would also avoid the situation that there is no clear governance and set of expectations around the code and a subproject goal: something we suffered from with the old ARM PV port (admittedly we didn't have governance then). In other words we have clear governance framework if, a) the worst case happens and the drivers start to become unmaintained and, b) if the best case happens and we suddenly get a lot of interest and there are arguments about ownership, process, decision making, ... * The option of separate infrastructure, e.g. a separate mailing list, would reduce trhe barrier of entry to the new subproject > 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") > Linux kernel code is developed under GPLv2 license, userspace > components like some backends are under Apache 2 license, so can be > integrated into software with commercial licenses. That is fine for subprojects in principle. Of course we prefer GPL, but any OSI approved license is fine (see http://opensource.org/licenses/alphabetical). > 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 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? > 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 Best Regards Lars [-- Attachment #1.2: Type: text/html, Size: 28162 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-04 14:22 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth @ 2014-06-04 16:35 ` Dario Faggioli 2014-06-05 12:47 ` Artem Mygaiev 0 siblings, 1 reply; 34+ messages in thread From: Dario Faggioli @ 2014-06-04 16:35 UTC (permalink / raw) To: lars.kurth; +Cc: Andrii Tseglytskyi, Artem Mygaiev, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 8600 bytes --] 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 #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-04 16:35 ` Dario Faggioli @ 2014-06-05 12:47 ` Artem Mygaiev 2014-06-05 13:32 ` Dario Faggioli ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Artem Mygaiev @ 2014-06-05 12:47 UTC (permalink / raw) To: Dario Faggioli; +Cc: Andrii Tseglytskyi, Lars Kurth, xen-devel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-05 12:47 ` Artem Mygaiev @ 2014-06-05 13:32 ` Dario Faggioli 2014-06-06 8:59 ` Ian Campbell 2014-06-11 11:37 ` Lars Kurth 2 siblings, 0 replies; 34+ messages in thread From: Dario Faggioli @ 2014-06-05 13:32 UTC (permalink / raw) To: Artem Mygaiev; +Cc: Andrii Tseglytskyi, Lars Kurth, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 3939 bytes --] On gio, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote: > Hi Dario, all > 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). > > 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? > 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. > > 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) > 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. > > Correct, this is our intention. Also, we dont think that QNX will ever > accept our code :) They are too OSS un-friendly... > 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 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. > Indeed. Thanks 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 #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-05 12:47 ` Artem Mygaiev 2014-06-05 13:32 ` Dario Faggioli @ 2014-06-06 8:59 ` Ian Campbell 2014-06-06 13:05 ` Lars Kurth 2014-06-11 11:37 ` Lars Kurth 2 siblings, 1 reply; 34+ messages in thread From: Ian Campbell @ 2014-06-06 8:59 UTC (permalink / raw) To: Artem Mygaiev; +Cc: Dario Faggioli, Lars Kurth, xen-devel, Andrii Tseglytskyi On Thu, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote: > > > [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 a bit concerned about this, since it sounds to me like it will eventually result in an automotive fork of xen.git. > > 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. Can't individual developers simply keep stuff in their personal trees or branches? If it then goes upstream that's great, but if it is an unsuitable "hack" then keeping it in a persons tree instead of in some formal subproject tree will neuter the possibility of an unintentional fork occurring. > > 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... I think you need to decide the correct home on a per-OS basis. e.g. Linux and BSD are OSS (and contribution) friendly so driver changes to those should always be done in the appropriate upstream, and therefore you don't require a subproject tree for them (individual developers can still have personal staging trees of course). If something like qnx is not OSS/contribution friendly then clearly does need it's own tree in the subproject. I think it would be up to you if you wanted to have a tree per-OS in that class or a single shared tree for all of them. Ian. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-06 8:59 ` Ian Campbell @ 2014-06-06 13:05 ` Lars Kurth 2014-06-06 15:08 ` Ian Campbell 0 siblings, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-06 13:05 UTC (permalink / raw) To: Ian Campbell, Artem Mygaiev Cc: Dario Faggioli, xen-devel, Ian Jackson, David Vrabel, Andrii Tseglytskyi [-- Attachment #1.1: Type: text/plain, Size: 6077 bytes --] On 06/06/2014 09:59, Ian Campbell wrote: > On Thu, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote: > >>>> [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 a bit concerned about this, since it sounds to me like it will > eventually result in an automotive fork of xen.git. I don't think this is the intention and *should not* be the intention. We are mixing up a long-term-home for official Xen Project PV drivers that don't fit elsewhere, such as * QNX * Maybe Linux user drivers (still waiting David Vrabel's view elsewhere on this thread) * Other OS'es which is the subject of this discussion. Officially supported Xen Project repositories should only depend on *upstreams* (Xen, Linux, ...). As we are talking about git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), whatever is in that repo (owned by a subproject) should build and work with vanilla Xen and Linux. For everything else - call it a personal or integration tree - we have git trees in git://xenbits.xen.org/people/* ... a bit more below. >>> 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. > Can't individual developers simply keep stuff in their personal trees or > branches? If it then goes upstream that's great, but if it is an > unsuitable "hack" then keeping it in a persons tree instead of in some > formal subproject tree will neuter the possibility of an unintentional > fork occurring. I suppose the confusion comes from terminology here. The GlobalLogic guys talk about "integration" trees, which in practice (I believe) have. They just happen to be the personal branches of Xen committers under git://xenbits.xen.org/people/* So there are several ways of how this could be handled: * GlobalLogic nominates one person (let's say Andrii as an example) and we may have git://xenbits.xen.org/people/andrii/xen.git, git://xenbits.xen.org/people/andrii/linux.git and git://xenbits.xen.org/people/andrii/pvdrivers.git which in essence becomes the "integration tree" for automotive/embedded work ** A slight variant may be to group people by interest, e.g. git://xenbits.xen.org/people/embedded or git://xenbits.xen.org/embedded/people to make it easier to spot who works on what - and assume that if there was no qualifier they work on the hypervisor. We had done this for Hg in the past with XCP: so this is not entirely new. * Or we could create something like git://xenbits.xen.org/integration/pvdrivers/*.git or git://xenbits.xen.org/people/integration/pvdrivers/*.git which may be shared by several people, but these could be treated as if they were in "people". * Or a combination of the above They may be subtle differences in "risks" of creating a fork, but on the other hand GlobalLogic already has it's own non-public fork within their org. In reality we are all working on ensuring there is no fork in the long-run. @Ian Jackson: this probably needs to be resolved before we create the personal branches for GlobalLogic, as the two things are dependant. >>> 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... > I think you need to decide the correct home on a per-OS basis. It seems there seem to be agreement that per-OS is the best way forward > e.g. Linux and BSD are OSS (and contribution) friendly so driver changes > to those should always be done in the appropriate upstream, and > therefore you don't require a subproject tree for them (individual > developers can still have personal staging trees of course). Can someone enlighten me why Linux user-space drivers may be different? This has come up at the BoF at the Dev Summit and also in this thread and is the only area where there is no full agreement on the way forward. > If something like qnx is not OSS/contribution friendly then clearly does > need it's own tree in the subproject. I think it would be up to you if > you wanted to have a tree per-OS in that class or a single shared tree > for all of them. Sounds reasonable Lars [-- Attachment #1.2: Type: text/html, Size: 12482 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-06 13:05 ` Lars Kurth @ 2014-06-06 15:08 ` Ian Campbell 2014-06-06 19:49 ` Artem Mygaiev 0 siblings, 1 reply; 34+ messages in thread From: Ian Campbell @ 2014-06-06 15:08 UTC (permalink / raw) To: lars.kurth Cc: Artem Mygaiev, Dario Faggioli, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi On Fri, 2014-06-06 at 14:05 +0100, Lars Kurth wrote: > On 06/06/2014 09:59, Ian Campbell wrote: > > > On Thu, 2014-06-05 at 13:47 +0100, Artem Mygaiev wrote: > > > > > > > [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 a bit concerned about this, since it sounds to me like it will > > eventually result in an automotive fork of xen.git. > I don't think this is the intention and *should not* be the intention. > We are mixing up a long-term-home for official Xen Project PV drivers > that don't fit elsewhere, such as > * QNX > * Maybe Linux user drivers (still waiting David Vrabel's view > elsewhere on this thread) > * Other OS'es > which is the subject of this discussion. Perhaps should be the subject of this discussion, but we had somehow ended up talking about Xen core changes. In particular there was talk of putting things into these staging trees which it was known would not go upstream ("things which should not leave staging tree"). At that point they are no longer a staging tree, they are a fork. That was what caused me to bring up my concern about forking. > Officially supported Xen Project repositories should only depend on > *upstreams* (Xen, Linux, ...). As we are talking about > git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), > whatever is in that repo (owned by a subproject) should build and work > with vanilla Xen and Linux. Is this pvdrivers.git going to be a descendent (e.g. a git clone) of xen.git? Or is it a fresh repository which contains this new set of drivers which do not have a home in xen.git? Are there going to be are repos in this new subproject which are derived from xen.git? What will be in them (hypervisor patches?) and what is intended to happen with them? > > > > 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. > > Can't individual developers simply keep stuff in their personal trees or > > branches? If it then goes upstream that's great, but if it is an > > unsuitable "hack" then keeping it in a persons tree instead of in some > > formal subproject tree will neuter the possibility of an unintentional > > fork occurring. > I suppose the confusion comes from terminology here. The GlobalLogic > guys talk about "integration" trees, which in practice (I believe) > have. Is a word missing from the last sentence? "they" perhaps? Or "we"? > They just happen to be the personal branches of Xen committers under > git://xenbits.xen.org/people/* Not just committers. I'm not really sure what you mean by "integration" trees. I suppose some of the trees under there might be "integration" trees most of them are just peoples various personal repos which they use for exchanging/referencing patches, sending branches as pull requests, sharing WIP stuff with random others etc. Ultimately what people keep in their personal trees under git://xenbits.xen.org/people/ is entirely their business (licensing, copyright relevance to xen etc aside), I don't think we should conflate that with subproject trees and "official" stuff. > So there are several ways of how this could be handled: > * GlobalLogic nominates one person (let's say Andrii as an example) > and we may have git://xenbits.xen.org/people/andrii/xen.git, > git://xenbits.xen.org/people/andrii/linux.git and > git://xenbits.xen.org/people/andrii/pvdrivers.git which in essence > becomes the "integration tree" for automotive/embedded work > ** A slight variant may be to group people by interest, e.g. > git://xenbits.xen.org/people/embedded or > git://xenbits.xen.org/embedded/people to make it easier to spot who > works on what - and assume that if there was no qualifier they work on > the hypervisor. We had done this for Hg in the past with XCP: so this > is not entirely new. > * Or we could create something like > git://xenbits.xen.org/integration/pvdrivers/*.git or > git://xenbits.xen.org/people/integration/pvdrivers/*.git which may be > shared by several people, but these could be treated as if they were > in "people". > * Or a combination of the above There seems to be a lot of mixing the concept of personal git trees with git trees related to subprojects, or at least it isn't always clear which one people are talking about. The two are very different things IMHO and it's not clear to me how any of the proposals you make above other than the first (the Andrii has a personal tree option) relates to the proposed new project being discussed in this thread. Putting subproject trees under /people/, which I'm not sure if you are proposing or not in some of the above options, is confusing. > They may be subtle differences in "risks" of creating a fork, but on > the other hand GlobalLogic already has it's own non-public fork within > their org. In reality we are all working on ensuring there is no fork > in the long-run. > > e.g. Linux and BSD are OSS (and contribution) friendly so driver changes > > to those should always be done in the appropriate upstream, and > > therefore you don't require a subproject tree for them (individual > > developers can still have personal staging trees of course). > Can someone enlighten me why Linux user-space drivers may be > different? There is no "upstream Linux user-space driver" project which these drivers can be contributed to. So either we become that upstream for Xen related drivers, or a new pvdrivers project does. > This has come up at the BoF at the Dev Summit and also in this thread > and is the only area where there is no full agreement on the way > forward. Ian. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-06 15:08 ` Ian Campbell @ 2014-06-06 19:49 ` Artem Mygaiev 2014-06-06 22:01 ` Dario Faggioli 2014-06-09 12:15 ` Lars Kurth 0 siblings, 2 replies; 34+ messages in thread From: Artem Mygaiev @ 2014-06-06 19:49 UTC (permalink / raw) To: Ian Campbell Cc: Dario Faggioli, Ian Jackson, xen-devel, Lars Kurth, David Vrabel, Andrii Tseglytskyi >> > > > > [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 a bit concerned about this, since it sounds to me like it will >> > eventually result in an automotive fork of xen.git. >> I don't think this is the intention and *should not* be the intention. >> We are mixing up a long-term-home for official Xen Project PV drivers >> that don't fit elsewhere, such as >> * QNX >> * Maybe Linux user drivers (still waiting David Vrabel's view >> elsewhere on this thread) >> * Other OS'es >> which is the subject of this discussion. > > Perhaps should be the subject of this discussion, but we had somehow > ended up talking about Xen core changes. In particular there was talk of > putting things into these staging trees which it was known would not go > upstream ("things which should not leave staging tree"). At that point > they are no longer a staging tree, they are a fork. That was what caused > me to bring up my concern about forking. Well, we do not have enough manpower to support "forks", otherwise we would create one somewhere long time ago. We want to a single work tree which we can use for development so it may have some _temporary_ hacks - and this is something we want to avoid! but it is not always possible. And we need a single tree since we are adding continuous integration and automated testing of xen on embedded platform(s). Of course, we will need to synchronise frequently, and we have someone to be responsible for this to not deviate from the mainline. Having said that, I perfectly understand your concerns - there are thousands of useless abandoned project forks in OSS world... >> Officially supported Xen Project repositories should only depend on >> *upstreams* (Xen, Linux, ...). As we are talking about >> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), >> whatever is in that repo (owned by a subproject) should build and work >> with vanilla Xen and Linux. > > Is this pvdrivers.git going to be a descendent (e.g. a git clone) of > xen.git? Or is it a fresh repository which contains this new set of > drivers which do not have a home in xen.git? pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of drivers that, as you said, do not have a home in xen.git or kernel.git > Are there going to be are repos in this new subproject which are derived > from xen.git? What will be in them (hypervisor patches?) and what is > intended to happen with them? There will be no repos derived from xen.git in the pvdrivers.git >> So there are several ways of how this could be handled: >> * GlobalLogic nominates one person (let's say Andrii as an example) >> and we may have git://xenbits.xen.org/people/andrii/xen.git, >> git://xenbits.xen.org/people/andrii/linux.git and >> git://xenbits.xen.org/people/andrii/pvdrivers.git which in essence >> becomes the "integration tree" for automotive/embedded work >> ** A slight variant may be to group people by interest, e.g. >> git://xenbits.xen.org/people/embedded or >> git://xenbits.xen.org/embedded/people to make it easier to spot who >> works on what - and assume that if there was no qualifier they work on >> the hypervisor. We had done this for Hg in the past with XCP: so this >> is not entirely new. >> * Or we could create something like >> git://xenbits.xen.org/integration/pvdrivers/*.git or >> git://xenbits.xen.org/people/integration/pvdrivers/*.git which may be >> shared by several people, but these could be treated as if they were >> in "people". >> * Or a combination of the above > > There seems to be a lot of mixing the concept of personal git trees with > git trees related to subprojects, or at least it isn't always clear > which one people are talking about. The two are very different things > IMHO and it's not clear to me how any of the proposals you make above > other than the first (the Andrii has a personal tree option) relates to > the proposed new project being discussed in this thread. > > Putting subproject trees under /people/, which I'm not sure if you are > proposing or not in some of the above options, is confusing. It seem to me that use of /people/ for subprojects may be misleading, too... The goal of our integration tree is to serve as a staging tree before upstreaming, hold all temporary hacks to support platforms and specific use cases and also for the needs of ci and qa... Having that code tested and working on automotive platforms like J6 we could be able to involve our clients to xen. Would something like xen.org/automotive.git or whatever similar be possible? >> > e.g. Linux and BSD are OSS (and contribution) friendly so driver changes >> > to those should always be done in the appropriate upstream, and >> > therefore you don't require a subproject tree for them (individual >> > developers can still have personal staging trees of course). >> Can someone enlighten me why Linux user-space drivers may be >> different? > > There is no "upstream Linux user-space driver" project which these > drivers can be contributed to. So either we become that upstream for Xen > related drivers, or a new pvdrivers project does. We would not mix userspace or non-Linux drivers with xen repo or Linux repo. We do believe that this shall be a separate project. 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-06 19:49 ` Artem Mygaiev @ 2014-06-06 22:01 ` Dario Faggioli 2014-06-09 10:18 ` Stefano Stabellini 2014-06-09 12:15 ` Lars Kurth 1 sibling, 1 reply; 34+ messages in thread From: Dario Faggioli @ 2014-06-06 22:01 UTC (permalink / raw) To: Artem Mygaiev Cc: Ian Campbell, Ian Jackson, xen-devel, Lars Kurth, David Vrabel, Andrii Tseglytskyi [-- Attachment #1.1: Type: text/plain, Size: 5127 bytes --] On Fri, 2014-06-06 at 22:49 +0300, Artem Mygaiev wrote: > > Perhaps should be the subject of this discussion, but we had somehow > > ended up talking about Xen core changes. In particular there was talk of > > putting things into these staging trees which it was known would not go > > upstream ("things which should not leave staging tree"). At that point > > they are no longer a staging tree, they are a fork. That was what caused > > me to bring up my concern about forking. > > Well, we do not have enough manpower to support "forks", otherwise we > would create one somewhere long time ago. > Well... I can't comment on the amount of manpower, but I'm happy that there's not a Xen-automotive fork, and that we're discussing this here, at least! :-D > We want to a single work > tree which we can use for development so it may have some _temporary_ > hacks - and this is something we want to avoid! but it is not always > possible. And we need a single tree since we are adding continuous > integration and automated testing of xen on embedded platform(s). Of > course, we will need to synchronise frequently, and we have someone to > be responsible for this to not deviate from the mainline. Having said > that, I perfectly understand your concerns - there are thousands of > useless abandoned project forks in OSS world... > Exactly. So, as I already first suggested and as Ian restated, I don't see the problem if this stating/temporary/integration/whatever tree is someone's personal tree. And I'm not saying that we should have subproject repo(s) under xenbits.org/people, I'm saying that, to get the bleeding edge of Xen for automotive, the version that supports all the feature and all the pvdrivers on all OSes, etc, you should clone and build Artem's git tree, or Andrii's one, or whatever other one... After all, although this predates my involvement in Xen, it's not long ago that, if one wanted to use Xen as Dom0, with all the coolest features, he needed to clone and track Jeremy's tree, or Konrad's one, is it? The only thing that needs, IMHO, to be clear, is whether or not there are non-upstreamable bits, and I'm talking about non-upstreamable in the long term. If there are, we've got a problem (and perhaps we should store the patches somewhere, as Ian was also said, or something like that). If there are not, if the goal is to upstream everything in xen.git and if we think such goal to be reasonable, and the problem is "only" <<but what about in the meantime>>, well, xenbits.org/people/xxx seems fine to me. After all, it's all a matter of what you tell people to clone and track, and on how you manage such tree yourself, deal with contributions from others, etc. What's wrong with this approach? > >> Officially supported Xen Project repositories should only depend on > >> *upstreams* (Xen, Linux, ...). As we are talking about > >> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), > >> whatever is in that repo (owned by a subproject) should build and work > >> with vanilla Xen and Linux. > > > > Is this pvdrivers.git going to be a descendent (e.g. a git clone) of > > xen.git? Or is it a fresh repository which contains this new set of > > drivers which do not have a home in xen.git? > > pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of > drivers that, as you said, do not have a home in xen.git or kernel.git > Indeed. What I've got in mind is something like the following: xenbits.org/[artem?]/xen-automotive.git integration tree xenbits.org/pvdrivers.git 'additional pvdrivers' (subproject?) tree I concur with Ian that the latter should host everything that does not have any proper upstream (like linux userspace components), or that can't be upstreamed for non technical reasons (like QNX components). What I'd allow is probably for some Linux *kernel* components, just out of convenience, although, again, I think the goal there should be similar to what we said wrt Xen: *upstream them all*!! :-D > > Putting subproject trees under /people/, which I'm not sure if you are > > proposing or not in some of the above options, is confusing. > > It seem to me that use of /people/ for subprojects may be misleading, > too... The goal of our integration tree is to serve as a staging tree > before upstreaming, hold all temporary hacks to support platforms and > specific use cases and also for the needs of ci and qa... Having that > code tested and working on automotive platforms like J6 we could be > able to involve our clients to xen. > Right. And if we call the pvdrivers the subproject, and put it somewhere else than /people, but we keep the xen tree under people --and not call it a subproject-- what's the problem your clients would face? 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 #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-06 22:01 ` Dario Faggioli @ 2014-06-09 10:18 ` Stefano Stabellini 2014-06-09 12:25 ` Lars Kurth 0 siblings, 1 reply; 34+ messages in thread From: Stefano Stabellini @ 2014-06-09 10:18 UTC (permalink / raw) To: Dario Faggioli Cc: Artem Mygaiev, Ian Campbell, Ian Jackson, xen-devel, Lars Kurth, David Vrabel, Andrii Tseglytskyi On Sat, 7 Jun 2014, Dario Faggioli wrote: > > >> Officially supported Xen Project repositories should only depend on > > >> *upstreams* (Xen, Linux, ...). As we are talking about > > >> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), > > >> whatever is in that repo (owned by a subproject) should build and work > > >> with vanilla Xen and Linux. > > > > > > Is this pvdrivers.git going to be a descendent (e.g. a git clone) of > > > xen.git? Or is it a fresh repository which contains this new set of > > > drivers which do not have a home in xen.git? > > > > pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of > > drivers that, as you said, do not have a home in xen.git or kernel.git > > > Indeed. What I've got in mind is something like the following: > > xenbits.org/[artem?]/xen-automotive.git integration tree > xenbits.org/pvdrivers.git 'additional pvdrivers' (subproject?) tree > > I concur with Ian that the latter should host everything that does not > have any proper upstream (like linux userspace components), or that > can't be upstreamed for non technical reasons (like QNX components). > What I'd allow is probably for some Linux *kernel* components, just out > of convenience, although, again, I think the goal there should be > similar to what we said wrt Xen: *upstream them all*!! :-D It sounds like we are heading toward creating both personal trees and pvdrivers.git. The personal trees would be personal trees like everybody else's: they could be used for WIP patch series and pull requests. They are no different from mine and yours. pvdrivers.git is the interesting one because it would be the upstream git repository for otherwise homeless pv drivers, such us userspace and QNX PV drivers. In my opinion Linux kernel drivers should stay in their personal git trees as WIP patch series until upsteamed. On Fri, 6 Jun 2014, Artem Mygaiev wrote: > > There seems to be a lot of mixing the concept of personal git trees with > > git trees related to subprojects, or at least it isn't always clear > > which one people are talking about. The two are very different things > > IMHO and it's not clear to me how any of the proposals you make above > > other than the first (the Andrii has a personal tree option) relates to > > the proposed new project being discussed in this thread. > > > > Putting subproject trees under /people/, which I'm not sure if you are > > proposing or not in some of the above options, is confusing. > > It seem to me that use of /people/ for subprojects may be misleading, > too... The goal of our integration tree is to serve as a staging tree > before upstreaming, hold all temporary hacks to support platforms and > specific use cases and also for the needs of ci and qa... Having that > code tested and working on automotive platforms like J6 we could be > able to involve our clients to xen. Would something like > xen.org/automotive.git or whatever similar be possible? Given that the staging tree would be a Linux tree plus a collection of non-upstreamable changes, I would keep it as a branch on one of your personal repositories. After all in the Linux world it is common to keep this kind of things as personal trees as you can see from git.kernel.org. Even the Linux tree that we used for OSSTests with Xen on ARM is just a branch on my personal Linux git repository for example. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 10:18 ` Stefano Stabellini @ 2014-06-09 12:25 ` Lars Kurth 2014-06-09 12:30 ` Ian Campbell 2014-06-09 12:37 ` Lars Kurth 0 siblings, 2 replies; 34+ messages in thread From: Lars Kurth @ 2014-06-09 12:25 UTC (permalink / raw) To: Stefano Stabellini, Dario Faggioli Cc: Artem Mygaiev, Ian Campbell, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi On 09/06/2014 11:18, Stefano Stabellini wrote: > On Sat, 7 Jun 2014, Dario Faggioli wrote: >>>>> Officially supported Xen Project repositories should only depend on >>>>> *upstreams* (Xen, Linux, ...). As we are talking about >>>>> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), >>>>> whatever is in that repo (owned by a subproject) should build and work >>>>> with vanilla Xen and Linux. >>>> Is this pvdrivers.git going to be a descendent (e.g. a git clone) of >>>> xen.git? Or is it a fresh repository which contains this new set of >>>> drivers which do not have a home in xen.git? >>> pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of >>> drivers that, as you said, do not have a home in xen.git or kernel.git >>> >> Indeed. What I've got in mind is something like the following: >> >> xenbits.org/[artem?]/xen-automotive.git integration tree I am assuming xen-automotive.git = xen.git with hacks (as a staging tree) So wouldn't it be better the to have xenbits/people/automotive/artem?/xen.git instead of a renamed tree? >> xenbits.org/pvdrivers.git 'additional pvdrivers' (subproject?) tree >> >> I concur with Ian that the latter should host everything that does not >> have any proper upstream (like linux userspace components), or that >> can't be upstreamed for non technical reasons (like QNX components). >> What I'd allow is probably for some Linux *kernel* components, just out >> of convenience, although, again, I think the goal there should be >> similar to what we said wrt Xen: *upstream them all*!! :-D Wouldn't that complicate merging, etc. It actually would only become convenient for building and terrible for upstreaming Which is why I argued for * xenbits.org/pvdrivers.git = clean and purely dependent on * xenbits.org/people/automotive/artem?/*.git to contain hacks for Linux kernel, etc. The workflow would be: * xenbits.org/people/automotive/artem?/*.git ... initial contribution and space to clean up hacks * xenbits.org/pvdrivers.git ... clean repo reflecting what is upstream. This is the final destination for PV drivers not living elsewhere. This is where the pvdrivers subproject would make releases from, etc. > It sounds like we are heading toward creating both personal trees and > pvdrivers.git. That was my assumption too. See earlier mail > The personal trees would be personal trees like everybody else's: they > could be used for WIP patch series and pull requests. They are no > different from mine and yours. Agreed > pvdrivers.git is the interesting one because it would be the upstream > git repository for otherwise homeless pv drivers, such us userspace and > QNX PV drivers. Agreed > > In my opinion Linux kernel drivers should stay in their personal git > trees as WIP patch series until upsteamed. Agreed Regards Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 12:25 ` Lars Kurth @ 2014-06-09 12:30 ` Ian Campbell 2014-06-09 13:14 ` Lars Kurth 2014-06-09 12:37 ` Lars Kurth 1 sibling, 1 reply; 34+ messages in thread From: Ian Campbell @ 2014-06-09 12:30 UTC (permalink / raw) To: lars.kurth Cc: Artem Mygaiev, Stefano Stabellini, Dario Faggioli, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi On Mon, 2014-06-09 at 13:25 +0100, Lars Kurth wrote: > On 09/06/2014 11:18, Stefano Stabellini wrote: > > On Sat, 7 Jun 2014, Dario Faggioli wrote: > >>>>> Officially supported Xen Project repositories should only depend on > >>>>> *upstreams* (Xen, Linux, ...). As we are talking about > >>>>> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), > >>>>> whatever is in that repo (owned by a subproject) should build and work > >>>>> with vanilla Xen and Linux. > >>>> Is this pvdrivers.git going to be a descendent (e.g. a git clone) of > >>>> xen.git? Or is it a fresh repository which contains this new set of > >>>> drivers which do not have a home in xen.git? > >>> pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of > >>> drivers that, as you said, do not have a home in xen.git or kernel.git > >>> > >> Indeed. What I've got in mind is something like the following: > >> > >> xenbits.org/[artem?]/xen-automotive.git integration tree > I am assuming xen-automotive.git = xen.git with hacks (as a staging tree) > So wouldn't it be better the to have > xenbits/people/automotive/artem?/xen.git instead of a renamed tree? Please can we keep subproject names out of the people namespace, it's just confusing things (i.e. is that an official repo of some sort or not?). /people/artem/xen.git is perfectly fine as a name for Artem's repo. Ian. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 12:30 ` Ian Campbell @ 2014-06-09 13:14 ` Lars Kurth 0 siblings, 0 replies; 34+ messages in thread From: Lars Kurth @ 2014-06-09 13:14 UTC (permalink / raw) To: Ian Campbell Cc: Artem Mygaiev, Stefano Stabellini, Dario Faggioli, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi On 09/06/2014 13:30, Ian Campbell wrote: > On Mon, 2014-06-09 at 13:25 +0100, Lars Kurth wrote: >> On 09/06/2014 11:18, Stefano Stabellini wrote: >>> On Sat, 7 Jun 2014, Dario Faggioli wrote: >>>>>>> Officially supported Xen Project repositories should only depend on >>>>>>> *upstreams* (Xen, Linux, ...). As we are talking about >>>>>>> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem), >>>>>>> whatever is in that repo (owned by a subproject) should build and work >>>>>>> with vanilla Xen and Linux. >>>>>> Is this pvdrivers.git going to be a descendent (e.g. a git clone) of >>>>>> xen.git? Or is it a fresh repository which contains this new set of >>>>>> drivers which do not have a home in xen.git? >>>>> pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of >>>>> drivers that, as you said, do not have a home in xen.git or kernel.git >>>>> >>>> Indeed. What I've got in mind is something like the following: >>>> >>>> xenbits.org/[artem?]/xen-automotive.git integration tree >> I am assuming xen-automotive.git = xen.git with hacks (as a staging tree) >> So wouldn't it be better the to have >> xenbits/people/automotive/artem?/xen.git instead of a renamed tree? > Please can we keep subproject names out of the people namespace, it's > just confusing things (i.e. is that an official repo of some sort or > not?). /people/artem/xen.git is perfectly fine as a name for Artem's > repo. /people/artem/xen.git is fine with me. Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 12:25 ` Lars Kurth 2014-06-09 12:30 ` Ian Campbell @ 2014-06-09 12:37 ` Lars Kurth 2014-06-09 13:12 ` Ian Jackson 1 sibling, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-09 12:37 UTC (permalink / raw) To: Stefano Stabellini, Dario Faggioli Cc: Artem Mygaiev, Ian Campbell, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi As an aside, it looks to me as if we were close enough to draft a subproject proposal on the wiki. As far I can see we agreed on * we need a subproject * we need an official xenbits.org/pvdrivers.git repo; it would also come with its own mailing list if desired * we agreed what can and cannot be in xenbits.org/pvdrivers.git * we agreed on licenses * in addition we need integration branches for xen.git, linux.git, pvdrivers.git - it appears that the consensus here is that we use the same pattern as elsewhere (aka the location for the staging branch is in xenbits.org/people). Maybe with some mods, e.g. people/automotive/* instead of people/* - although this is not yet finally agreed. There are still differing opinions on naming. The proposal should probably clarify some of the points raised in the thread, to remove any confusion. Regards Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 12:37 ` Lars Kurth @ 2014-06-09 13:12 ` Ian Jackson 2014-06-09 13:31 ` Lars Kurth 0 siblings, 1 reply; 34+ messages in thread From: Ian Jackson @ 2014-06-09 13:12 UTC (permalink / raw) To: lars.kurth Cc: Artem Mygaiev, Ian Campbell, Stefano Stabellini, Dario Faggioli, xen-devel, David Vrabel, Andrii Tseglytskyi Lars Kurth writes ("Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request"): > As an aside, > > it looks to me as if we were close enough to draft a subproject proposal > on the wiki. As far I can see we agreed on > * we need a subproject I would just like to quibble with your pathnames. I think that the subproject should have its own subdirectory, which should contain all of its repos. So: > * we need an official xenbits.org/pvdrivers.git repo; it would also come > with its own mailing list if desired > * in addition we need integration branches for xen.git, linux.git, > pvdrivers.git - it appears that the consensus here is that we use the > same pattern as elsewhere Rather, we should have: xenbits.xen.org/automotive/pvdrivers.git xenbits.xen.org/automotive/linux.git xenbits.xen.org/automotive/xen.git etc. (FSVO "automotive"; I currently have no opinion about the project name.) Cf xenbits.xen.org/xenclient/, xenbits.xen.org/kemari/, xenbits.xen.org/xcp/, xenbits.xen.org/xenrt-citrix/ ... NB these are mostly git url fragments, not http url fragments. So eg "xenbits.xen.org/xenrt-citrix/" contains "xenrt.git" which is accessible via git clone git://xenbits.xen.org/xenrt-citrix/xenrt.git (and also via the gitweb index etc.) If it is helpful there is no technical reason why it would be difficult to provide a subproject with a webtree on xenbits that would be accessible via http://xenbits.xen.org/subproject/. But we don't want xenbits to be used for general-purpose web hosting. AIUI this particular subproject doesn't have a requirement at this stage for a separate web hosting setup. > (aka the location for the staging branch is in xenbits.org/people). > Maybe with some mods, e.g. people/automotive/* instead of people/* - > although this is not yet finally agreed. There are still differing > opinions on naming. I agree with Ian Campbell that we do not want subproject names in people/. That is strictly for human beings, and contains only "unofficial" repos. Thanks, Ian. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 13:12 ` Ian Jackson @ 2014-06-09 13:31 ` Lars Kurth 2014-06-10 14:22 ` Artem Mygaiev 0 siblings, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-09 13:31 UTC (permalink / raw) To: Ian Jackson Cc: Artem Mygaiev, Ian Campbell, Stefano Stabellini, Dario Faggioli, xen-devel, David Vrabel, Andrii Tseglytskyi On 09/06/2014 14:12, Ian Jackson wrote: > Lars Kurth writes ("Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request"): >> As an aside, >> >> it looks to me as if we were close enough to draft a subproject proposal >> on the wiki. As far I can see we agreed on >> * we need a subproject > I would just like to quibble with your pathnames. I think that the > subproject should have its own subdirectory, which should contain all > of its repos. I don't mind. I missed the convention you outlined > So: > >> * we need an official xenbits.org/pvdrivers.git repo; it would also come >> with its own mailing list if desired >> * in addition we need integration branches for xen.git, linux.git, >> pvdrivers.git - it appears that the consensus here is that we use the >> same pattern as elsewhere > Rather, we should have: > > xenbits.xen.org/automotive/pvdrivers.git > xenbits.xen.org/automotive/linux.git > xenbits.xen.org/automotive/xen.git > etc. > > (FSVO "automotive"; I currently have no opinion about the project > name.) That would make sense. So we follow the convention xenbits.xen.org/<subproject name>/pvdrivers.git However, if we allowed linux.git and xen.git in xenbits.xen.org/<subproject name>, it does increase the risk of creating a permanent fork (i.e. the main concerns raised by IanC, Stefano, etc.) > Cf xenbits.xen.org/xenclient/, xenbits.xen.org/kemari/, > xenbits.xen.org/xcp/, xenbits.xen.org/xenrt-citrix/ ... > > > NB these are mostly git url fragments, not http url fragments. So eg > "xenbits.xen.org/xenrt-citrix/" contains "xenrt.git" which is > accessible via > git clone git://xenbits.xen.org/xenrt-citrix/xenrt.git > (and also via the gitweb index etc.) > > If it is helpful there is no technical reason why it would be > difficult to provide a subproject with a webtree on xenbits that would > be accessible via http://xenbits.xen.org/subproject/. But we don't > want xenbits to be used for general-purpose web hosting. > > AIUI this particular subproject doesn't have a requirement at this > stage for a separate web hosting setup. I wasn't aware of it. And we don't need it >> (aka the location for the staging branch is in xenbits.org/people). >> Maybe with some mods, e.g. people/automotive/* instead of people/* - >> although this is not yet finally agreed. There are still differing >> opinions on naming. > I agree with Ian Campbell that we do not want subproject names in > people/. That is strictly for human beings, and contains only > "unofficial" repos. OK. Regards Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-09 13:31 ` Lars Kurth @ 2014-06-10 14:22 ` Artem Mygaiev 2014-06-10 14:51 ` Lars Kurth 0 siblings, 1 reply; 34+ messages in thread From: Artem Mygaiev @ 2014-06-10 14:22 UTC (permalink / raw) To: Lars Kurth Cc: Ian Campbell, Stefano Stabellini, Dario Faggioli, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi [-- Attachment #1.1: Type: text/plain, Size: 1332 bytes --] > > So: >> >> * we need an official xenbits.org/pvdrivers.git repo; it would also come >>> with its own mailing list if desired >>> * in addition we need integration branches for xen.git, linux.git, >>> pvdrivers.git - it appears that the consensus here is that we use the >>> same pattern as elsewhere >>> >> Rather, we should have: >> >> xenbits.xen.org/automotive/pvdrivers.git >> xenbits.xen.org/automotive/linux.git >> xenbits.xen.org/automotive/xen.git >> etc. >> >> (FSVO "automotive"; I currently have no opinion about the project >> name.) >> > That would make sense. So we follow the convention xenbits.xen.org/<subproject > name>/pvdrivers.git > I like the idea :) However, if we allowed linux.git and xen.git in xenbits.xen.org/<subproject > name>, it does increase the risk of creating a permanent fork (i.e. the > main concerns raised by IanC, Stefano, etc.) True. But this is always a risk (like with mentioned XenRT), even without staging trees in subprojects. To me it is more a matter of maintainers' and community discipline... Artem Mygaiev | AVP - Delivery GlobalLogic P +380.44.4929695 ext.2023 M +380.67.9211131 S rosenkrantzguildenstern www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt [-- Attachment #1.2: Type: text/html, Size: 4049 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-10 14:22 ` Artem Mygaiev @ 2014-06-10 14:51 ` Lars Kurth 0 siblings, 0 replies; 34+ messages in thread From: Lars Kurth @ 2014-06-10 14:51 UTC (permalink / raw) To: Artem Mygaiev Cc: Ian Campbell, Stefano Stabellini, Dario Faggioli, Ian Jackson, xen-devel, David Vrabel, Andrii Tseglytskyi [-- Attachment #1.1: Type: text/plain, Size: 867 bytes --] On 10/06/2014 15:22, Artem Mygaiev wrote: > > However, if we allowed linux.git and xen.git in xenbits.xen.org/ > <http://xenbits.xen.org/><subproject name>, it does increase the > risk of creating a permanent fork (i.e. the main concerns raised > by IanC, Stefano, etc.) > > > True. But this is always a risk (like with mentioned XenRT), even > without staging trees in subprojects. To me it is more a matter of > maintainers' and community discipline... How about xenbits.xen.org/ <http://xenbits.xen.org/><subproject name>/staging/ for the staging trees, if there is consensus to do this. But we can leave this open for now: it's not blocking us from moving forward I have enough to work on a formal subproject proposal and started at http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal Regards Lars [-- Attachment #1.2: Type: text/html, Size: 2197 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-06 19:49 ` Artem Mygaiev 2014-06-06 22:01 ` Dario Faggioli @ 2014-06-09 12:15 ` Lars Kurth 1 sibling, 0 replies; 34+ messages in thread From: Lars Kurth @ 2014-06-09 12:15 UTC (permalink / raw) To: Artem Mygaiev, Ian Campbell Cc: Dario Faggioli, xen-devel, Ian Jackson, David Vrabel, Andrii Tseglytskyi On 06/06/2014 20:49, Artem Mygaiev wrote: >>>>>>> [need input] Should these be owned by a separate subproject or >>>>>>> attached to an existing subproject (e.g. the Hypervisor project) [snip] >> There seems to be a lot of mixing the concept of personal git trees with >> git trees related to subprojects, or at least it isn't always clear >> which one people are talking about. The two are very different things >> IMHO and it's not clear to me how any of the proposals you make above >> other than the first (the Andrii has a personal tree option) relates to >> the proposed new project being discussed in this thread. >> >> Putting subproject trees under /people/, which I'm not sure if you are >> proposing or not in some of the above options, is confusing. > It seem to me that use of /people/ for subprojects may be misleading, > too... The goal of our integration tree is to serve as a staging tree > before upstreaming, hold all temporary hacks to support platforms and > specific use cases and also for the needs of ci and qa... Having that > code tested and working on automotive platforms like J6 we could be > able to involve our clients to xen. Would something like > xen.org/automotive.git or whatever similar be possible? Sorry for the confusion. What I was trying to say: * We would have an official tree pvdrivers.git tree owned by the subproject aka xenbits/pvdrivers.git alongside xenbits/xen, which works with upstream linux and xen.git. No hacks allowed in there. * In *addition* we would need integration or personal repos (however we want to call them) as work-in-progress and development branches for linux, xen and pvdrivers.git - these could contain some hacks for a limited period. The reason is because the code as it is contains some dependencies on hacks elsewhere. This discussion was about the naming of the best naming convention for this integration tree. I wasn't arguing for moving the official tree of the subproject into the people directory >>> Can someone enlighten me why Linux user-space drivers may be >>> different? >> There is no "upstream Linux user-space driver" project which these >> drivers can be contributed to. So either we become that upstream for Xen >> related drivers, or a new pvdrivers project does. > We would not mix userspace or non-Linux drivers with xen repo or Linux > repo. We do believe that this shall be a separate project. OK. This makes sense. So if we are all agreed pvdrivers.git can contain "user-space Linux drivers", but maybe we can label them by calling the directory in which these sit as linux-user or some other terminology that makes this clear (and avoids debate) Regards Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-05 12:47 ` Artem Mygaiev 2014-06-05 13:32 ` Dario Faggioli 2014-06-06 8:59 ` Ian Campbell @ 2014-06-11 11:37 ` Lars Kurth 2 siblings, 0 replies; 34+ messages in thread From: Lars Kurth @ 2014-06-11 11:37 UTC (permalink / raw) To: Artem Mygaiev, Dario Faggioli; +Cc: Andrii Tseglytskyi, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 4879 bytes --] On 05/06/2014 13:47, Artem Mygaiev wrote: >>>> 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 It is not clear to me whether this would work. So let me try and clarify through a few questions. Question 1: Can the QNX drivers be built with free and open source software only (e.g. GCC)? If the answer is yes, that would solve most of the problem. If not, we need to look into other options (in a similar way as we needed to do this for http://wiki.xenproject.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal - where Visual Studio is necessary for individuals to build and test and thus ultimately to contribute to the drivers) Question 2: Can the QNX drivers be tested with free and open source software only or is some code under proprietary license necessary? And related we probably need some HW to test stuff on in future also? IMHO being able to test the QNX drivers, should be a long-term goal of the subproject. To do this, the Xen Project may have to purchase a QNX license for a test machine and some HW. There are several ways to do this: * Short term: A vendor could decide to test on behalf of the community. We have done this before. But it is not ideal in the long-run. * Long term: We may need some funds from the AB (or a donation from a non-AB vendor) to enable this. * Long term: it is conceivable that the Xen Project may be counted as "Non-Commercial Developers", in which case at least the software for future test infrastructure could be obtained for free for the Xen Project. This does not have to be solved straight away and is IMHO not blocking the progress of this subproject proposal. Also, we have found a way to address this for http://wiki.xenproject.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal @Artem: Any guidance would be helpful Note 3: As for a nice development environment such as an IDE: it is IMHO acceptable for an IDE to be available under a commercial license, as long as an FOSS alternative (e.g. GCC, GDB, ...) is available. I did check http://www.qnx.org.uk/legal/licensing/non_commercial.html which seems to imply that there is a free license for "Non-Commercial Developers". The term seems "Non-Commercial Developers" to be tied to individuals not working for a commercial end-purpose, which is likely good enough. But I have not checked the detailed terms. This document also seems to have some provision for open source projects ("non-commercial group projects") - although the terminology is not clear and not specific. So I am not sure whether we would count as a "non-commercial group project" and whether say a Linux Foundation Collaborative project would be able to get a development tools for a build and test service under the "Non-Commercial Developers" clause for free. @Artem: Any guidance would be helpful Question 4: I tripped over http://www.qnx.org.uk/legal/licensing/crm.html which raises some questions related to QNX licenses and what license we would host QNX drivers under. I believe - I will need to check this with the Linux Foundation - that as a Collaborative Project we can only host code under OSI approved licenses. So we would need to find a compatible OSI approved license for the QNX drivers. There also seems to be a note that some QNX software is available under Apache licenses (see http://www.qnx.org.uk/legal/licensing/open_source.html). I guess what this comes down to is whether QNX would allow us to make available a QNX BSP for Xen Project software under an OSI approved license (e.g. Apache 2.0). There is a statement in http://www.qnx.org.uk/legal/licensing/open_source.html which says "QSS [QNX Software Systems] has begun publishing QNX board support package (BSP) software under the Apache License, Version 2.0 (Apache 2.0). Members of the QNX developer community are encouraged to use their Momentics Tools to create BSPs to allow the QNX RTOS to run on a wider variety of hardware platforms [without stating that publication under Apache 2 is encouraged - but it sort of implies it]". This implies that maybe we are OK, but it needs checking. @Artem, this is probably something you will need to follow up on and provide us with some more clarity. This would potentially be a blocking issue for the proposal. Regards Lars [-- Attachment #1.2: Type: text/html, Size: 7433 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-04 13:04 Automotive PV drivers project request Artem Mygaiev 2014-06-04 14:22 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth @ 2014-06-04 14:36 ` Roger Pau Monné 2014-06-04 15:21 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth 2014-06-05 13:17 ` Automotive PV drivers project request David Vrabel 2 siblings, 1 reply; 34+ messages in thread From: Roger Pau Monné @ 2014-06-04 14:36 UTC (permalink / raw) To: Artem Mygaiev, xen-devel On 04/06/14 15: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.) > 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 > Linux kernel code is developed under GPLv2 license, userspace > components like some backends are under Apache 2 license, so can be > integrated into software with commercial licenses. 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. Hello, Most of the Xen PV frontends/backends inside of the Linux kernel are under a dual-license like the following (this one is from blkfront): * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License version 2 * as published by the Free Software Foundation; or, when distributed * separately from the Linux kernel or incorporated into other * software packages, subject to the following license: * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this source file (the "Software"), to deal in the Software without * restriction, including without limitation the rights to use, copy, modify, * merge, publish, distribute, sublicense, and/or sell copies of the Software, * and to permit persons to whom the Software is furnished to do so, subject to * the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS * IN THE SOFTWARE. Which allows them to be imported/shared with other OSes. Could you consider releasing the Linux drivers under this kind of license? Thanks, Roger. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-04 14:36 ` Automotive PV drivers project request Roger Pau Monné @ 2014-06-04 15:21 ` Lars Kurth 2014-06-04 15:34 ` Roger Pau Monné 0 siblings, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-04 15:21 UTC (permalink / raw) To: Roger Pau Monné, Artem Mygaiev, xen-devel, Andrii Tseglytskyi > Which allows them to be imported/shared with other OSes. Could you consider > releasing the Linux drivers under this kind of license? @Roger: Can you explain why this is a good idea? Apart from consitency I think I know, but am not 100% sure. I suppose there are benefits for the likes of MiniOS, BSD, ... Lars On 04/06/2014 15:36, Roger Pau Monné wrote: > On 04/06/14 15: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.) >> 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 >> Linux kernel code is developed under GPLv2 license, userspace >> components like some backends are under Apache 2 license, so can be >> integrated into software with commercial licenses. 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. > Hello, > > Most of the Xen PV frontends/backends inside of the Linux kernel are > under a dual-license like the following (this one is from blkfront): > > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License version 2 > * as published by the Free Software Foundation; or, when distributed > * separately from the Linux kernel or incorporated into other > * software packages, subject to the following license: > * > * Permission is hereby granted, free of charge, to any person obtaining a copy > * of this source file (the "Software"), to deal in the Software without > * restriction, including without limitation the rights to use, copy, modify, > * merge, publish, distribute, sublicense, and/or sell copies of the Software, > * and to permit persons to whom the Software is furnished to do so, subject to > * the following conditions: > * > * The above copyright notice and this permission notice shall be included in > * all copies or substantial portions of the Software. > * > * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > * IN THE SOFTWARE. > > Which allows them to be imported/shared with other OSes. Could you > consider releasing the Linux drivers under this kind of license? > > Thanks, Roger. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-04 15:21 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth @ 2014-06-04 15:34 ` Roger Pau Monné 2014-06-05 13:07 ` Artem Mygaiev 0 siblings, 1 reply; 34+ messages in thread From: Roger Pau Monné @ 2014-06-04 15:34 UTC (permalink / raw) To: lars.kurth, Artem Mygaiev, xen-devel, Andrii Tseglytskyi On 04/06/14 17:21, Lars Kurth wrote: >> Which allows them to be imported/shared with other OSes. Could you > consider >> releasing the Linux drivers under this kind of license? > > @Roger: Can you explain why this is a good idea? Apart from consitency > I think I know, but am not 100% sure. I suppose there are benefits for > the likes of MiniOS, BSD, ... So that those drivers can be imported into other OSes which are not under the GPL. As you say, I was mainly thinking about MiniOS and BSDs. Roger. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Need Input] (informal) Automotive PV drivers subproject request 2014-06-04 15:34 ` Roger Pau Monné @ 2014-06-05 13:07 ` Artem Mygaiev 0 siblings, 0 replies; 34+ messages in thread From: Artem Mygaiev @ 2014-06-05 13:07 UTC (permalink / raw) To: Roger Pau Monné; +Cc: Andrii Tseglytskyi, Lars Kurth, xen-devel Roger, Lars, If there's a good reason (and I think there is) to use the dual-license, we'll go for it 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 On Wed, Jun 4, 2014 at 4:34 PM, Roger Pau Monné <roger.pau@citrix.com> wrote: > On 04/06/14 17:21, Lars Kurth wrote: >>> Which allows them to be imported/shared with other OSes. Could you >> consider >>> releasing the Linux drivers under this kind of license? >> >> @Roger: Can you explain why this is a good idea? Apart from consitency >> I think I know, but am not 100% sure. I suppose there are benefits for >> the likes of MiniOS, BSD, ... > > So that those drivers can be imported into other OSes which are not > under the GPL. As you say, I was mainly thinking about MiniOS and BSDs. > > Roger. > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-04 13:04 Automotive PV drivers project request Artem Mygaiev 2014-06-04 14:22 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth 2014-06-04 14:36 ` Automotive PV drivers project request Roger Pau Monné @ 2014-06-05 13:17 ` David Vrabel 2014-06-05 13:22 ` Artem Mygaiev 2 siblings, 1 reply; 34+ messages in thread From: David Vrabel @ 2014-06-05 13:17 UTC (permalink / raw) To: Artem Mygaiev, xen-devel On 04/06/14 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.) > 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 > Linux kernel code is developed under GPLv2 license, userspace > components like some backends are under Apache 2 license, so can be > integrated into software with commercial licenses. 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. I don't want to see Linux drivers languishing in a sub-project -- they should all be merged into Linux proper. David ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-05 13:17 ` Automotive PV drivers project request David Vrabel @ 2014-06-05 13:22 ` Artem Mygaiev 2014-06-10 12:38 ` David Vrabel 0 siblings, 1 reply; 34+ messages in thread From: Artem Mygaiev @ 2014-06-05 13:22 UTC (permalink / raw) To: David Vrabel; +Cc: xen-devel David, agree on all kernel drivers but what about userspace backends and other OSes? 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 On Thu, Jun 5, 2014 at 2:17 PM, David Vrabel <david.vrabel@citrix.com> wrote: > On 04/06/14 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.) >> 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 >> Linux kernel code is developed under GPLv2 license, userspace >> components like some backends are under Apache 2 license, so can be >> integrated into software with commercial licenses. 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. > > I don't want to see Linux drivers languishing in a sub-project -- they > should all be merged into Linux proper. > > David ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-05 13:22 ` Artem Mygaiev @ 2014-06-10 12:38 ` David Vrabel 2014-06-10 14:09 ` Lars Kurth 0 siblings, 1 reply; 34+ messages in thread From: David Vrabel @ 2014-06-10 12:38 UTC (permalink / raw) To: Artem Mygaiev; +Cc: xen-devel On 05/06/14 14:22, Artem Mygaiev wrote: > David, agree on all kernel drivers but what about userspace backends > and other OSes? I don't have an opinion on user space drivers. I would suggest that userspace backends live with the existing ones in qemu. Are userspace frontends useful? Isn't a kernel driver required for proper access control? David ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-10 12:38 ` David Vrabel @ 2014-06-10 14:09 ` Lars Kurth 2014-06-10 14:18 ` Artem Mygaiev 0 siblings, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-10 14:09 UTC (permalink / raw) To: David Vrabel, Artem Mygaiev; +Cc: xen-devel On 10/06/2014 13:38, David Vrabel wrote: > On 05/06/14 14:22, Artem Mygaiev wrote: >> David, agree on all kernel drivers but what about userspace backends >> and other OSes? > I don't have an opinion on user space drivers. I would suggest that > userspace backends live with the existing ones in qemu. > > Are userspace frontends useful? Isn't a kernel driver required for > proper access control? David, I believe the answer is in http://wiki.xenproject.org/wiki/XPDS13_BoF_Notes_:_Seeding_an_Android_and_Embedded_ecosystem#Missing_Pieces_for_a_complete_Android_system_on_top_of_Xen As far as I understand, Android requires functionality to be made available via userspace drivers. These would sit on top of the kernel drivers. Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-10 14:09 ` Lars Kurth @ 2014-06-10 14:18 ` Artem Mygaiev 2014-06-11 10:10 ` Stefano Stabellini 0 siblings, 1 reply; 34+ messages in thread From: Artem Mygaiev @ 2014-06-10 14:18 UTC (permalink / raw) To: Lars Kurth; +Cc: David Vrabel, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --] David, Lars, Indeed, userspace drivers in Android essentially are set of so libraries for libhardware which provides some sort of a HAL to kenel drivers. In order to simplify things we can avoid kernel drivers in Andorid and go straight to userspace. I do not think that it is correct to mix PV drivers backends with QEMU, we do not do full emulation in most cases, just PVHVM Artem Mygaiev | AVP - Delivery GlobalLogic P +380.44.4929695 ext.2023 M +380.67.9211131 S rosenkrantzguildenstern www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt On Tue, Jun 10, 2014 at 5:09 PM, Lars Kurth <lars.kurth@xen.org> wrote: > On 10/06/2014 13:38, David Vrabel wrote: > >> On 05/06/14 14:22, Artem Mygaiev wrote: >> >>> David, agree on all kernel drivers but what about userspace backends >>> and other OSes? >>> >> I don't have an opinion on user space drivers. I would suggest that >> userspace backends live with the existing ones in qemu. >> >> Are userspace frontends useful? Isn't a kernel driver required for >> proper access control? >> > David, > > I believe the answer is in http://wiki.xenproject.org/ > wiki/XPDS13_BoF_Notes_:_Seeding_an_Android_and_Embedded_ecosystem#Missing_ > Pieces_for_a_complete_Android_system_on_top_of_Xen > > As far as I understand, Android requires functionality to be made > available via userspace drivers. These would sit on top of the kernel > drivers. > > Lars > [-- Attachment #1.2: Type: text/html, Size: 4597 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request 2014-06-10 14:18 ` Artem Mygaiev @ 2014-06-11 10:10 ` Stefano Stabellini 2014-06-11 15:08 ` Automotive PV drivers project request (need more input) Lars Kurth 0 siblings, 1 reply; 34+ messages in thread From: Stefano Stabellini @ 2014-06-11 10:10 UTC (permalink / raw) To: Artem Mygaiev; +Cc: Lars Kurth, David Vrabel, xen-devel [-- Attachment #1: Type: text/plain, Size: 2096 bytes --] On Tue, 10 Jun 2014, Artem Mygaiev wrote: > David, Lars, > > Indeed, userspace drivers in Android essentially are set of so libraries for libhardware which provides some sort of a HAL > to kenel drivers. In order to simplify things we can avoid kernel drivers in Andorid and go straight to userspace. > > I do not think that it is correct to mix PV drivers backends with QEMU, we do not do full emulation in most cases, just > PVHVM You don't need to do any emulation whatsoever in order to run the PV backends in QEMU. You can simply execute QEMU to provide only the PV backends and nothing else by passing -M xenpv. In fact we use QEMU as userspace PV backend provider for x86 PV guests, that do not require any emulation on the hypervisor side at all. Having the PV backends in QEMU gives you a common framework to write PV drivers and access xenstore (see hw/xen/xen_backend.c). > 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 > > > On Tue, Jun 10, 2014 at 5:09 PM, Lars Kurth <lars.kurth@xen.org> wrote: > On 10/06/2014 13:38, David Vrabel wrote: > On 05/06/14 14:22, Artem Mygaiev wrote: > David, agree on all kernel drivers but what about userspace backends > and other OSes? > > I don't have an opinion on user space drivers. I would suggest that > userspace backends live with the existing ones in qemu. > > Are userspace frontends useful? Isn't a kernel driver required for > proper access control? > > David, > > I believe the answer is inhttp://wiki.xenproject.org/wiki/XPDS13_BoF_Notes_:_Seeding_an_Android_and_Embedded_ecosystem#Missing_Pieces_for_a_complet > e_Android_system_on_top_of_Xen > > As far as I understand, Android requires functionality to be made available via userspace drivers. These would sit > on top of the kernel drivers. > > Lars > > > > [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request (need more input) 2014-06-11 10:10 ` Stefano Stabellini @ 2014-06-11 15:08 ` Lars Kurth 2014-06-12 9:34 ` Stefano Stabellini 0 siblings, 1 reply; 34+ messages in thread From: Lars Kurth @ 2014-06-11 15:08 UTC (permalink / raw) To: Stefano Stabellini, Artem Mygaiev Cc: Andrii Tseglytskyi, Ian Jackson, David Vrabel, Paul Durrant, xen-devel Hi all, I collated this thread into http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal This raises a number of extra questions besides the licensing questions I raised to Artem earlier. Q1: should we have separate git repos per OS, e.g. git://xenbits.xen.org/pvdrivers/xen-linux-user-drivers.git git://xenbits.xen.org/pvdrivers/xen-qnx-drivers.git instead of git://xenbits.xen.org/pvdrivers/pvdrivers.git This sounds more user friendly and scalable Q2: should http://wiki.xen.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal & http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal share infrastructure (e.g. lists, web portal, git://xenbits.xen.org/pvdrivers/) or even be merged There is no clear-cut answer. Arguments against merging: * Forces people with very different interests into one subproject (aka creates unnecessary noise) * Dilutes Project Leadership Arguments for merging: * Critical mass for graduation is more easily reached (but may be fake) * Increases chances of building a sustainable community If we don't merge, we should not use the generic label "pvdrivers" for xenbits and mailing lists for this proposal, but use something more specific. We also need a label for the Windows PV driver project. Best Regards Lars ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request (need more input) 2014-06-11 15:08 ` Automotive PV drivers project request (need more input) Lars Kurth @ 2014-06-12 9:34 ` Stefano Stabellini 2014-06-12 13:43 ` Paul Durrant 0 siblings, 1 reply; 34+ messages in thread From: Stefano Stabellini @ 2014-06-12 9:34 UTC (permalink / raw) To: Lars Kurth Cc: Artem Mygaiev, Stefano Stabellini, Ian Jackson, xen-devel, Paul Durrant, David Vrabel, Andrii Tseglytskyi On Wed, 11 Jun 2014, Lars Kurth wrote: > Hi all, > > I collated this thread into > http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal > > This raises a number of extra questions besides the licensing questions I > raised to Artem earlier. > > Q1: should we have separate git repos per OS, e.g. > git://xenbits.xen.org/pvdrivers/xen-linux-user-drivers.git > git://xenbits.xen.org/pvdrivers/xen-qnx-drivers.git > > instead of > git://xenbits.xen.org/pvdrivers/pvdrivers.git > > This sounds more user friendly and scalable Sounds like a good idea to me > Q2: should > http://wiki.xen.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposal & > http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal > share infrastructure (e.g. lists, web portal, > git://xenbits.xen.org/pvdrivers/) or even be merged > > There is no clear-cut answer. > > Arguments against merging: > * Forces people with very different interests into one subproject (aka creates > unnecessary noise) > * Dilutes Project Leadership > > Arguments for merging: > * Critical mass for graduation is more easily reached (but may be fake) > * Increases chances of building a sustainable community > > If we don't merge, we should not use the generic label "pvdrivers" for xenbits > and mailing lists for this proposal, but use something more specific. We also > need a label for the Windows PV driver project. I think that using the generic name "pvdrivers" is a good idea and would encourage other people with different pvdrivers for other OSes to join the effort. So maybe we do need to unify the Windows PV drivers project. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Automotive PV drivers project request (need more input) 2014-06-12 9:34 ` Stefano Stabellini @ 2014-06-12 13:43 ` Paul Durrant 0 siblings, 0 replies; 34+ messages in thread From: Paul Durrant @ 2014-06-12 13:43 UTC (permalink / raw) To: Lars Kurth Cc: Artem Mygaiev, xen-devel, Stefano Stabellini, David Vrabel, Ian Jackson, Andrii Tseglytskyi > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: 12 June 2014 10:34 > To: Lars Kurth > Cc: Stefano Stabellini; Artem Mygaiev; David Vrabel; xen- > devel@lists.xen.org; Andrii Tseglytskyi; Ian Jackson; Paul Durrant > Subject: Re: [Xen-devel] Automotive PV drivers project request (need more > input) > > On Wed, 11 Jun 2014, Lars Kurth wrote: > > Hi all, > > > > I collated this thread into > > > http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_ > Proposal > > > > This raises a number of extra questions besides the licensing questions I > > raised to Artem earlier. > > > > Q1: should we have separate git repos per OS, e.g. > > git://xenbits.xen.org/pvdrivers/xen-linux-user-drivers.git > > git://xenbits.xen.org/pvdrivers/xen-qnx-drivers.git > > > > instead of > > git://xenbits.xen.org/pvdrivers/pvdrivers.git > > > > This sounds more user friendly and scalable > > > Sounds like a good idea to me > > > > Q2: should > > > http://wiki.xen.org/wiki/Windows_PV_Drivers_Incubation_Project_Proposa > l & > > > http://wiki.xen.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_ > Proposal > > share infrastructure (e.g. lists, web portal, > > git://xenbits.xen.org/pvdrivers/) or even be merged > > > > There is no clear-cut answer. > > > > Arguments against merging: > > * Forces people with very different interests into one subproject (aka > creates > > unnecessary noise) > > * Dilutes Project Leadership > > > > Arguments for merging: > > * Critical mass for graduation is more easily reached (but may be fake) > > * Increases chances of building a sustainable community > > > > If we don't merge, we should not use the generic label "pvdrivers" for > xenbits > > and mailing lists for this proposal, but use something more specific. We also > > need a label for the Windows PV driver project. > > I think that using the generic name "pvdrivers" is a good idea and would > encourage other people with different pvdrivers for other OSes to join > the effort. So maybe we do need to unify the Windows PV drivers project. IMO, Windows PV drivers are a sufficiently distinct codebase, and will almost certainly remain so, that the sub-project should be independent. There's already a long history of (different sets of) Windows PV drivers for Xen and a loose community surrounding them, which the project is aiming to unify around a existent common codebase. I think it would very much confuse things to try to combine these sub-projects. Paul ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2014-06-12 13:43 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-04 13:04 Automotive PV drivers project request Artem Mygaiev 2014-06-04 14:22 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth 2014-06-04 16:35 ` Dario Faggioli 2014-06-05 12:47 ` Artem Mygaiev 2014-06-05 13:32 ` Dario Faggioli 2014-06-06 8:59 ` Ian Campbell 2014-06-06 13:05 ` Lars Kurth 2014-06-06 15:08 ` Ian Campbell 2014-06-06 19:49 ` Artem Mygaiev 2014-06-06 22:01 ` Dario Faggioli 2014-06-09 10:18 ` Stefano Stabellini 2014-06-09 12:25 ` Lars Kurth 2014-06-09 12:30 ` Ian Campbell 2014-06-09 13:14 ` Lars Kurth 2014-06-09 12:37 ` Lars Kurth 2014-06-09 13:12 ` Ian Jackson 2014-06-09 13:31 ` Lars Kurth 2014-06-10 14:22 ` Artem Mygaiev 2014-06-10 14:51 ` Lars Kurth 2014-06-09 12:15 ` Lars Kurth 2014-06-11 11:37 ` Lars Kurth 2014-06-04 14:36 ` Automotive PV drivers project request Roger Pau Monné 2014-06-04 15:21 ` [Need Input] (informal) Automotive PV drivers subproject request Lars Kurth 2014-06-04 15:34 ` Roger Pau Monné 2014-06-05 13:07 ` Artem Mygaiev 2014-06-05 13:17 ` Automotive PV drivers project request David Vrabel 2014-06-05 13:22 ` Artem Mygaiev 2014-06-10 12:38 ` David Vrabel 2014-06-10 14:09 ` Lars Kurth 2014-06-10 14:18 ` Artem Mygaiev 2014-06-11 10:10 ` Stefano Stabellini 2014-06-11 15:08 ` Automotive PV drivers project request (need more input) Lars Kurth 2014-06-12 9:34 ` Stefano Stabellini 2014-06-12 13:43 ` Paul Durrant
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.