On Wed, Jun 15, 2011 at 7:50 PM, Woodruff, Robert J <robert.j.woodr...@intel.com> wrote: > Michael wrote, >>For those of us that are not hardcore kernel developers can you >>explain what this change would actually do? I'm not sure i understand >>how having a source tree with the patches already applied is any >>different then taking the base kernel and applying a patch tree. But >>then again i probably don't understand what your talking about at all >>(me == admin not developer). > > Well what I would like to understand is what would you like to see ? > > A tar ball or complete patch with the OFED drivers for each kernel that OFED > supports > that can be applied to the kernel tree so that the kernel can be built using > the normal kernel build process ? > > Or > > A complete kernel tree with all of the OFED drivers already included that > could be > downloaded via tar balls or git ? > > Other ? >
I'm not sure I'm really qualified to answer such a question (nor whether i can write what i want to say legibly), but I'll take a stab at it. First off you should note i can only speak to redhat and rpmbuild processes, we don't use sles or any other distro where i work (so my answer is definitely biased). For me personally, the only time I rebuild the kernel is when I have to build a lustre server, which is not all that often. The steps i take (in brevity) are: unpack kernel source from redhat edit spec file to include lustre patches rebuild kernel rpms using rpmbuild (redhat process) install new kernel reboot into new kernel use ofed install.pl -s /<lustre kernel tree> install ofed rpms reboot make lustre source using --with-linux=<lustre kernel tree> --with-o2ib=/usr/src/ofa_kernel Even though I'm not really answering your question, I'm not sure the change really makes any difference to me. I can't really foresee a need where i would want a full kernel tree versus patches. I'm sure scenario's exist where it would be beneficial to have one method over the other, but for me i can't think of one. I would hazard a guess that the majority of people are in the same boat as me with kernel rebuilds nope, even sitting here racking my brain some more, i can't see a need for a full kernel tree for me. even if i was rebuilding the kernel and kernel-ib sections i'd still want to use the redhat rpmbuild process, which will patch vanilla 2.6.18 to 2.6.18-238, and then i'd add whatever patches i needed to the end of rhel's patch tree just like i did with lustre and let the spec file do all the work i guess if i was an IB developer though, having a git tree of 2.6.18 with all the RHEL and IB patches applied to it would probably be handy though. i can only guess that having full git trees might make porting patches to other kernel versions easier (not a dev don't really know). how do ports get created today? does each developer have to basically create a kernel dev tree and test their patch against it and see what breaks? dunno if i helped or wasted everyone's time, but that's my two cents... -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
