[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.