Christos Triantafyllidis
2011-Jun-17 19:15 UTC
[Lustre-discuss] Patchless client modules on fedora14
Hi, i managed to build the patchless modules for fedora14 kernel (2.6.35.13-92.fc14) using the attached patch against the 1.8.5.56 tag from git.whamcloud.com [1]. Most of the work is for supporting kernels like 2.6.35 and not fedora specific. If one wants to build the patchless modules for fedora14, he will need the complete fedora kernel headers [2] installed. I hope to receive comments on the patch, especially if i broke something :). Regards, Christos [1] http://git.whamcloud.com/?p=fs/lustre-release.git;a=tree;h=2498ec5c6ccf2e460cee330953e932861d84a9c3;hb=0b646024add0042784926153b1c835cbe19d74be [2] http://www.g-loaded.eu/2005/12/14/the-complete-fedora-kernel-headers/ -------------- next part -------------- A non-text attachment was scrubbed... Name: lustre-fedora14.patch Type: application/octet-stream Size: 20060 bytes Desc: not available Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20110617/688bcc39/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3330 bytes Desc: not available Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20110617/688bcc39/attachment.bin
Andreas Dilger
2011-Jun-17 20:36 UTC
[Lustre-discuss] Patchless client modules on fedora14
On 2011-06-17, at 1:15 PM, Christos Triantafyllidis wrote:> i managed to build the patchless modules for fedora14 kernel (2.6.35.13-92.fc14) using the attached patch against the 1.8.5.56 tag from git.whamcloud.com [1]. > > Most of the work is for supporting kernels like 2.6.35 and not fedora specific. If one wants to build the patchless modules for fedora14, he will need the complete fedora kernel headers [2] installed. > > I hope to receive comments on the patch, especially if i broke something :).Thanks for sending this in. The patch looks reasonable at first glance, but as it stands right now it is not suitable for landing, since it will break building for all of the earlier kernels. What you need to do is: - file a bug for tracking this work: http://jira.whamcloud.com/ - Make configure checks for each change - libcfs/autoconf/lustre-libcfs.m4 and lustre/autoconf/lustre-core.m4 for many examples. Each check should have a short description, the kernel version in which the change appeared (so it can be removed later when those kernels are obsolete), and be located in numerical order of the kernel version, to make that easier - Make compatibility functions to handle the API changes as needed - libcfs/include/libcfs/linux/portals_compat25.h for functions affecting everything, and lustre/include/lustre/linux/lustre_compat25.h for VFS functions that only affect the lustre/ code - These checks+fixes should be split into small patches (one API change per patch) so that they can be inspected, tested, and landed separately. Several times in the past someone submits a huge patch with dozens of different changes in it, but it can''t be landed as-is for one reason or another, and it gets delayed and has to be refreshed repeatedly. Making small patches means the obvious ones can be landed quickly, the tricky ones can be inspected/tested more thoroughly and they do not block the simple ones from landing. Cheers, Andreas -- Andreas Dilger Principal Engineer Whamcloud, Inc.