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 asOn 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 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/*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.
It seems there seem to be agreement that per-OS is the best way forwardThis 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.
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.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).
Sounds reasonableIf 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.