On 13-03-01 8:05 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble<nitin.a.kam...@intel.com>
Hi Bruce,
I have prepared commits for enabling non-transparent-bridge and
Crystal-Beach-DMA/DCA drivers in the kernel.
This is needed to implement features in this bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2465
I have created a new "ntb" git branch for the ntb feature. The branch is pushed
here:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/ntb
As it is a new branch for kernel repo, I am not sending individual commits over
ML.
You can directly fetch the ntb branch in the v3.8 repo.
And new features for ioatdma (aka Crystal Beach DMA/DCA)& ntb (non transparent
bridge)
are created in the meta branch over here:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta
Nitin,
In general this looks pretty good. I've been tracking NTB development
for quite some time, so luckily I'm aware of the challenges working
with the feature.
Just a few questions.
- I assume this has passed build tests ?
- Who's doing the NTB runtime testing ? I've seen this code in the past,
and while it builds relatively easily .. getting it tested is more
of a challenge.
And a request .. I realize that this wouldn't have been obvious when you
were working on this, but that's what the mailing list review is for!
This feature in particular shouldn't be staged as a branch and merged, so
just set it up as a .scc file (as you have it) without the patches. If you
want the patches to be applied whenever ntb-common.scc is included, let
me know and that's where I'll place them. I'll then merge these changes
to the standard/base branch to make them available to all BSPs.
You are probably wondering why it shouldn't be a topic branch and
merged. The reason comes down to the fact that it will conflict with
both mainline development and BSP work. This is an active area of
development (and hence bug fixing as well), so the chances of a topic
branch conflicting and failing to merge are high. I'll need to resolve
those conflicts in tree while stacking patches, I can't do that with
a topic branch.
Features that usually get a topic branch are:
- features that are largely developed out of tree
- features that are orthogonal to other code in the tree, and don't
touch many common files
- features that may have active development, where we want to track
the history separately (versus patch based history) or we want to
track a significant amount of commits.
- features that will update/upgrade and migrate over time.
- "just because" :)
With that set of criteria, things like graphics drivers (emgd, or
schedulers (EDF)) get topic branches. But other features like
preempt-rt (it will always conflict) or lttng-1.x don't get topic
branches. And that's why ntb really shouldn't have one either. IF
we have to many topic branches, we'll end up with patch time merge
failures of the topic branches .. which are difficult to resolve.
It should be a simple thing to re-order (since the content is all
largely the same) .. and will take less time that I did typing all
this up :)
Cheers,
Bruce
Thanks,
Nitin
The following changes since commit c2ed0f16fdec628242a682897d5d86df4547cf24:
checkpoint dir: meta (2013-02-24 22:43:59 -0500)
are available in the git repository at:
git://git.yoctoproject.org/linux-yocto-contrib nitin/meta
http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/meta
Nitin A Kamble (2):
new feature for non-transparent-bridge driver
new feature for I/OAT DMA driver
meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg | 1 +
meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc | 1 +
meta/cfg/kernel-cache/features/ntb/ntb.cfg | 1 +
meta/cfg/kernel-cache/features/ntb/ntb.scc | 2 ++
4 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.cfg
create mode 100644 meta/cfg/kernel-cache/features/ioatdma/ioatdma.scc
create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.cfg
create mode 100644 meta/cfg/kernel-cache/features/ntb/ntb.scc
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
