[ewg] [PATCH] OFED/kernel_addons - fix compiler warnings in 2.6.9_U5
hi vlad, here is a patch which fixes a couple
compiler warnings for me on 2.6.9_U5...
arthur
commit 3440f69777a4d29590d437308f364f22ada84e9b
Author: Arthur Jones [EMAIL PROTECTED]
Date: Thu Dec 13 12:07:40 2007 -0800
OFED/kernel_addons - fix compiler warnings in 2.6.9_U5 build
request irq from outside does not have struct pt_regs *,
so take that parameter out. this fixes a couple compiler
warnings that i see in 2.6.9_U5 builds
Signed-off-by: Arthur Jones [EMAIL PROTECTED]
diff --git a/kernel_addons/backport/2.6.9_U5/include/linux/interrupt.h
b/kernel_addons/backport/2.6.9_U5/include/linux/interrupt.h
index ffddfa0..5252f7b 100644
--- a/kernel_addons/backport/2.6.9_U5/include/linux/interrupt.h
+++ b/kernel_addons/backport/2.6.9_U5/include/linux/interrupt.h
@@ -4,7 +4,7 @@
static inline int
backport_request_irq(unsigned int irq,
- irqreturn_t (*handler)(int, void *, struct pt_regs *),
+ irqreturn_t (*handler)(int, void *),
unsigned long flags, const char *dev_name, void *dev_id)
{
return request_irq(irq,
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] which kernel addons w/ RHEL5.0?
hi vlad, which kernel_addons backport directory goes with RHEL5 (no updates) in your build tests? arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ofed_kernel merged with 2.6.24-rc1 patches update required
hi vladimir, are the backport patches posted to an open mailing list somewhere? i would like to see them on (general|ewg)@openfabrics.org so that they can be reviewed before going in to your tree. occasionally i do see them on these lists, but, i don't think they are all seeing these lists before hitting your tree... arthur On Mon, Oct 29, 2007 at 05:01:45PM +0200, Vladimir Sokolovsky wrote: Hello, There is a new branch ofed_kernel_2_6_24_rc1 under git://git.openfabrics.org/ofed_1_3/linux-2.6.git All patches from kernel_patches/fixes that were applied in 2.6.24-rc1 were removed from kernel_patches/fixes directory. The problematic patches from kernel_patches/fixes were moved to the kernel_patches/attic directory. Backport patches and fixes should be updated according to the new kernel tree. The easy way to do so is using ofed_scripts/ofed_makedist.sh utility which creates tgz file for every supported kernel with all relevant patches applied. We want to move to the new branch on this Wednesday (31 Oct 2007) Please send me updated backport patches and fixes by tomorrow. Regards, Vladimir ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Wed, Jul 25, 2007 at 10:27:23AM +0300, Michael S. Tsirkin wrote: - A single git reset ORIG_HEAD recovers from a conflicting merge handling conflicts is a big part of a maintainer's job! Because you are a driver maintainer. That's what's different here from regular merge. Please understand: we have upstream code and we have changes against it. i am a driver maintainer, but i'm also maintaining the ipath release which is OFED + qlogic specific stuff. i know the process that you go through to make a release. i've lived it now for 2 releases of ipath software. Upstream code is golden. If some patch conflicts with it, it is always this patch that needs to be fixed. And I want to ability to bounce that job to patch author - I simply do not know enough about e.g. ehca. i agree, non-trivial merges should be bounced to the patch author -- nothing about using backport branches prevents or even makes this more difficult, in fact, i have found it to be easier in git than in dealing w/ patches because the environment where the changes need to be made is much more comfortable (git rather than quilt or some random patch stack)... also, if the upstream changes touch code that conflicts with a backport patch, you get to fix the problem as it happens That's exactly the thing that I do not want to do. you don't want to know about a problem a patch until days or weeks later when the auto build keeps failing and you don't know why? it is easy to catch many problems _before_ the build check fails... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsirkin wrote: [...] But I also see a serious problem with addressing: basically git tracks content. It's not designed to track a bush of branches taken together. For example, take tagging: tag namespace is global, so you can not have the same tag point at multiple branches at the same time. agreed. however, the way we use git, with the location of the git DB as the tag, it's not really a problem in practice. but tagging each branch separately is indeed a PITA... anyway, what do you think? is there anyway i could convince you to dump the backport patches and put all the backports in branches? i'm willing to do the legwork if you see value... Can you publish the scripts and/or the tree? I think we can start by just running the scripts nightly, making it possible for people to view backport history with gitview. i've attached the script that i'm using to compare the trees, but it's a total hack. it doesn't keep the patch history. that would not be too hard to do i guess -- if there's interest... to run the script: cp attached files here... $ git clone git://git.openfabrics.org/~mst/ofed_kernel.git ofed_kernel $ cd ofed_kernel $ for b in `cat ../ofed-backports.txt`; do ../create-backport.sh $b; done now you'll have a bunch of backport-2.6.xxx branches... arthur 2.6.5_sles9_sp3 2.6.9_U2 2.6.9_U3 2.6.9_U4 2.6.9_U5 2.6.11_FC4 2.6.11 2.6.12 2.6.13_suse10_0_u 2.6.13 2.6.14 2.6.15_ubuntu606 2.6.15 2.6.16_sles10 2.6.16_sles10_sp1 2.6.16 2.6.17 2.6.18_FC6 2.6.18 2.6.19 2.6.20 2.6.21 2.6.22 create-backport.sh Description: Bourne shell script ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Tue, Jul 24, 2007 at 06:09:09PM +0300, Michael S. Tsirkin wrote: Quoting Arthur Jones [EMAIL PROTECTED]: Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits hi michael, ... On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsirkin wrote: [...] But I also see a serious problem with addressing: basically git tracks content. It's not designed to track a bush of branches taken together. For example, take tagging: tag namespace is global, so you can not have the same tag point at multiple branches at the same time. agreed. however, the way we use git, with the location of the git DB as the tag, it's not really a problem in practice. who uses git this way? i do. but tagging each branch separately is indeed a PITA... This is just one problem. For example, git pull can only merge one branch at a time. how is this a problem? the way i use git, i use a script to reflow the changes into the dependent branches. over the last few months, anyway, it has worked fine... anyway, what do you think? is there anyway i could convince you to dump the backport patches and put all the backports in branches? i'm willing to do the legwork if you see value... can you publish the scripts and/or the tree? i think we can start by just running the scripts nightly, making it possible for people to view backport history with gitview. i've attached the script that i'm using to compare the trees, but it's a total hack. it doesn't keep the patch history. that would not be too hard to do i guess -- if there's interest... to run the script: cp attached files here... $ git clone git://git.openfabrics.org/~mst/ofed_kernel.git ofed_kernel $ cd ofed_kernel $ for b in `cat ../ofed-backports.txt`; do ../create-backport.sh $b; done now you'll have a bunch of backport-2.6.xxx branches... So, would you like to have this script run nightly on ofed trees? if someone finds that useful. my main motivation is getting rid of all the patches in ofed, if running this script nightly helps us to get there, then i'm all for it. if it's just for me, it's easy enough to run the scripts by hand... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Tue, Jul 24, 2007 at 06:53:48PM +0300, Michael S. Tsirkin wrote: [...] well, no, i _have_ been doing development on the local branches in our internal repo. i also merge in changes that you make to the ofed repo to our internal backport branches. the script i posted is just so that i can more easily compare our internal branches to the ofed backport branches. How do you do the merging? for just the backport branches, i merge different ways from different sources: * from upstream, it's a pull into master and a git merge master into local backport branches -- i call this a reflow. * from local developers, it's a git pull straight into the backport branch, then reflow the repo. * from ofed, i apply the backport patch by hand and fixup the inevitable clashes -- either because part of the patch is already applied, or because context has changed enough for git apply to get confused. when these are fixed up, reflow the repo... If people start developing on these branches, then eventually you will need to merge them - and git only merges them one at a time. yes, i have to merge them one at a time. i still don't see how this is a problem. backport changes can be pulled in and the changes from upstream can be merged in as well. i haven't had a problem with this so far. can you be more specific about what you expect will fail? Well, as distro maintainers we need to merge a lot, from different people. We'll have to write all kind of scripts to do it instead of a plain git pull. i can't imagine what script you would need. can you be more specific? it would seem to me that you could just pull straight in to the backport branch... And, I expect almost all git operations will have to be wrapped in a script in some way, to operate on a bush of branches. so far, this hasn't been an issue for me. the only operation that i've scripted is the reflow. for most work, i can just ignore the backport branches and do the work in the (copy of) master, then reflow the changes into the backports... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Tue, Jul 24, 2007 at 08:19:24PM +0300, Michael S. Tsirkin wrote: i realize that you're attached to your current method, but i've _used_ a different method, and i can say from experience that it works _much_ better... I'd like to see a clean method, that doesn't replace one set of problems that I understand with another that I have to learn. i think we'll be further along by just doing a better job rather than waiting endlessly for perfection to come along. i'd _really_ like to see a list of the advantages of patches over branches. it's hard for me to know if i'm just missing something if the case is not laid out... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Tue, Jul 24, 2007 at 08:52:20PM +0300, Michael S. Tsirkin wrote: i'd _really_ like to see a list of the advantages of patches over branches. it's hard for me to know if i'm just missing something if the case is not laid out... thanks for the list... Here's a short list off the top of my head - A single git pull merges any number of backport changes ok, you can run one command instead of a 4-line script. hmm, i guess you could say this is a very slight advantage to using patches... - A single git reset ORIG_HEAD recovers from a conflicting merge handling conflicts is a big part of a maintainer's job! the _vast_ majority of the time i bet you already know how to do the merge. if you don't, then only the backport branches which haven't merged yet are stuck and you can pick up where you left off (which is how i do it now). but if you're stuck in some strange intermediate state with some patches pushed and some yet to push in the configure script, i could see how you'd want to punt. but, someone is doing this work, and that someone almost certainly has a difficult time reproducing and developing a stack of patches.. if, though, you must have a pristine environment, this is easily solved by using an intermediate repo: git clone -s canonical repo run the pull any conflicts, dump this guy, otherwise, pull this in i bet this is very similar time-wise to running the merge, then the ofed_scripts/configure over all supported branches. merges in git are _fast_... - A single tag tags all code for all kernels store commit ids in a file and tag that? - On update from upstream, if there is a conflict between upstream code and and a patch it's easy to temporarily remote the patch, complete the merge, and go bugger the patch author i think this is easier with the backport branches, see git clone -s above. or, just fixup the error. the reason you have to bugger the author may be that you don't have the tools necessary to actually fix up the patch -- but you can prob bet the author doesn't like to fixup patches in quilt any more than you do... - For recent kernels there are almost no patches. So an update from upstream for these kernels is free, with branches I will still need to update all branches. i can say from a couple months experience that upstream merges are free using backport branches. running the script to reflow the branches is _far_ less complex than the configure script, has fewer dependencies and is much simpler to maintain and understand. also, if the upstream changes touch code that conflicts with a backport patch, you get to fix the problem as it happens in a much more comfortable environment (i.e. you don't need quilt)... - Adding a fix which only affects common code is currently straight-forward: make a change, commit. With multiple branches every fix must be pulled into all branches. this use case is actually a good reason to use backport branches. with the patches, you still need to fan out the changes to all the backport branches. but, in general, you don't. so you end up making a change and _not realizing_ that it broke some random backport patch. by reflowing after every change, you get to see it break right there in front of you and you're way more likely to know how to fix it. you could do this with the build script too, but that would require a 4 line script -- and you'd need to switch over to using quilt or some other patch queue based system (yuck!)... all your points above you made from the POV of the maintainer. but, what about the _users_ of the repo. as long as changes are kept as patches, trying to figure out what has changed with your latest round of backports comes down to recreating a tree and pulling from that. it's extremely fragile and error prone. there is only one maintainer, but many developers. if we can make their lives significantly easier then it should be a net gain... the backport branches make merging upstream changes easier. they make merging developer changes easier. they make finding and fixing backport conflicts easier. they make viewing and navigating changes easier. but, you need to use very short scripts (which i'm happy to create and maintain) to tag and pull -- doesn't seem like much of a price to pay to me... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote: For whom it may concern, I have created an ofed git tree updated with kernel bits from 2.6.22-rc4, and put that up at git://git.openfabrics.org/~mst/ofed_kernel.git [...] In particular, there were a ton of ipath patches that it seems were for the most part applied. Qlogic maintainers, please help double check that I did not miss something of value. thanks for setting this up, i'm still looking at the diffs to make sure things got setup correctly for the ipath stuff... i have found it difficult to navigate the source having to run: ./ofed_scripts/configure --kernel-version=2.6.xxx --without-quilt everytime to check against our tree. so, rather than spending the better part of the afternoon running these scripts by hand, i created a shell script to populate a bunch of branches with the backports in each branch. at qlogic we now keep the backports as branches in our git tree and this, i find, is much easier to handle. because: * viewing and navigating backport source becomes _much_ easier. * merges are easier -- patches are much more fragile than branches. * comparisons are easier -- checking for differences between backports and between a backport and the canonical source is faster and more convenient... * changesets are readable. trying to decipher diffs to patches is medically proven to take months, if not years, off your life. anyway, what do you think? is there anyway i could convince you to dump the backport patches and put all the backports in branches? i'm willing to do the legwork if you see value... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
