Summary: | [science-overlay] openib-userspace-1.2.5.1-r2 what can be used with in kernel drivers | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexey Shvetsov <alexxy> |
Component: | New packages | Assignee: | Gentoo Cluster Team <cluster> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | bgreen0, sci |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 223957 | ||
Attachments: |
openib-userspace-1.2.5.1-r2.ebuild
openib openib.modprobe |
Description
Alexey Shvetsov
![]() ![]() Created attachment 154581 [details]
openib-userspace-1.2.5.1-r2.ebuild
ebuild
Created attachment 154583 [details]
openib
openib.init.d
Created attachment 154585 [details]
openib.modprobe
openib.modprobe
Is there any reason to be using sys-cluster/openib-drivers given that the drivers are already in the kernel? I'd rather use the linux eclass's to check for openib support in the kernel and then install just the userspace items. Also, consider using "cat <<-EOF >${t}/openib.conf" instead of all of those crazy echos! :) For instance: cat <<-EOF >${T}/openib.conf # Load UCM module echo "UCM_LOAD=no EOF That, or just distribute a conf file with the ebuild in the filesdir. (In reply to comment #4) > Is there any reason to be using sys-cluster/openib-drivers given that the > drivers are already in the kernel? I'd rather use the linux eclass's to check > for openib support in the kernel and then install just the userspace items. The openib-drivers ebuild installs the drivers provided by a particular OFED release, which is generally more current that what is in the kernel. In addition, some modules, such as SDP, are not yet in the kernel mainline. By using openib-drivers with openib-userspace, you are getting a complete OFED distribution. (In reply to comment #5) > > The openib-drivers ebuild installs the drivers provided by a particular OFED > release, which is generally more current that what is in the kernel. In > addition, some modules, such as SDP, are not yet in the kernel mainline. > By using openib-drivers with openib-userspace, you are getting a complete OFED > distribution. > Yes. But openib-drivers works only with 2.6.21 and 2.6.22 kernels. So if you have newer one you intended to use in kernel drivers. So please commit this ebuild to science overlay BTW ofed-1.3 was out about two mouth ago. (In reply to comment #6) > > So please commit this ebuild to science overlay I'm running into a little problem with this ebuild. I have openib-drivers and openib-userspace installed, and when I try to upgrade with the new ebuild, it gets a conflict and fails (after completing the entire compilation) because it detects a file colision with the '/etc/init.d/openib' file installed by openib-drivers. The solution of course is to set the new 'modules' use flag. But the random user isn't going to know this - they'll see it as a breakage. It would be nice to either maintain the current default behavior, which is to assume the openib init script and configuration are provided by openib-drivers, or else to fail early (if openib-drivers is already installed) with a message to the user to add the 'modules' use flag. Thoughts? > BTW ofed-1.3 was out about two mouth ago. I know. I took a quick look at it, and they seem to have changed the package layout substantially. Creating a new ebuild will be somewhat non-trivial. Unfortunately, I don't have the time resources to jump on that myself right now. :( (In reply to comment #7) > (In reply to comment #6) > > > > So please commit this ebuild to science overlay > > I'm running into a little problem with this ebuild. > I have openib-drivers and openib-userspace installed, > and when I try to upgrade with the new ebuild, it gets a conflict and fails > (after completing the entire compilation) because it detects a file colision > with the '/etc/init.d/openib' file installed by openib-drivers. > The solution of course is to set the new 'modules' use flag. But the random > user isn't going to know this - they'll see it as a breakage. It would be nice > to either maintain the current default behavior, which is to assume the openib > init script and configuration are provided by openib-drivers, or else to fail > early (if openib-drivers is already installed) with a message to the user to > add the 'modules' use flag. > Thoughts? One suggestion I can offer: instead of the 'modules' use flag, have a 'nomodules' or 'initscripts' use flag. Would that work for you? (In reply to comment #8) > > One suggestion I can offer: instead of the 'modules' use flag, have a > 'nomodules' or 'initscripts' use flag. Would that work for you? > May its better to check kernel version And if its greater than 2.6.22 then warn user that opeib-kernel doesn't work And as partial solution: modules may be enabled by default. (In reply to comment #9) > (In reply to comment #8) > > > > One suggestion I can offer: instead of the 'modules' use flag, have a > > 'nomodules' or 'initscripts' use flag. Would that work for you? > > > > May its better to check kernel version > And if its greater than 2.6.22 then warn user that opeib-kernel doesn't work Thats a good idea, but it doesn't address the problem of maintaining current behavior (for someone with openib-drivers already installed). > And as partial solution: modules may be enabled by default. I'm not aware that that is possible. (In reply to comment #10) > > May its better to check kernel version > > And if its greater than 2.6.22 then warn user that opeib-kernel doesn't work > > Thats a good idea, but it doesn't address the problem of maintaining current > behavior (for someone with openib-drivers already installed). > > > And as partial solution: modules may be enabled by default. > > I'm not aware that that is possible. > Another solution is check if openib-kernel already installed and check if modules use set or unset. If openib-kernel is instlled and modules not set then stop merging userspace this error and war user about use flag and in kernel drivers. PS i can try to make split ebuilds for ofed-1.3 (In reply to comment #11) > (In reply to comment #10) > > > May its better to check kernel version > > > And if its greater than 2.6.22 then warn user that opeib-kernel doesn't work > > > > Thats a good idea, but it doesn't address the problem of maintaining current > > behavior (for someone with openib-drivers already installed). > > > > > And as partial solution: modules may be enabled by default. > > > > I'm not aware that that is possible. > > > > Another solution is check if openib-kernel already installed and check if > modules use set or unset. If openib-kernel is instlled and modules not set then > stop merging userspace this error and war user about use flag and in kernel > drivers. I could perhaps do that as an intermediate solution, but I think the longer term solution is to update the 'openib-files' package to provide the up-to-date versions of these files, instead of duplicating them in openib-drivers and -userspace. Do you happen to recall offhand what the ebuild function is the test for the presence of another installed package? > PS i can try to make split ebuilds for ofed-1.3 Any contributions are welcome. :) (In reply to comment #12) > I could perhaps do that as an intermediate solution, but I think the longer > term solution is to update the 'openib-files' package to provide the up-to-date > versions of these files, instead of duplicating them in openib-drivers and > -userspace. For what it's worth, I concur :) > Do you happen to recall offhand what the ebuild function is the test for the > presence of another installed package? portageq or has_version, both in ebuild.sh (In reply to comment #13) > (In reply to comment #12) > > I could perhaps do that as an intermediate solution, but I think the longer > > term solution is to update the 'openib-files' package to provide the up-to-date > > versions of these files, instead of duplicating them in openib-drivers and > > -userspace. > > For what it's worth, I concur :) > Okay, I've added ebuilds for the 1.2.5.5 release. The new -userspace and -drivers ebuilds pull in openib-files for the system files. This should fix the problem. Hopefully I can put together 1.3.* ebuilds before too long. Please try openib-usrespace-1.2.5.5, and see if it addresses your needs. (In reply to comment #4) > Also, consider using "cat <<-EOF >${t}/openib.conf" instead of all of those > crazy echos! :) For instance: > > cat <<-EOF >${T}/openib.conf > # Load UCM module > echo "UCM_LOAD=no > EOF > > That, or just distribute a conf file with the ebuild in the filesdir. I agree that the above is nicer. Actually, the reason for the echos is that it is a fairly straightforward cut-and-paste from the OFED ofa_kernel.spec file, which is what creates the openib.conf file during RPM installation. I think the best thing would be a sed/awk script to automate the cut/paste. Thanks =) I'll gonna try this today =) BTW I can try to make split ebuilds for 1.3.1 may be it will be more simple then monolitic one =) BTW I think that openib files needs to install newenvd also with ---------CUT HERE-------- IBPATH="/usr/bin" ---------CUT HERE-------- something like .etc/env.d/02openib This env varieble needed because it used by some scripts like ibnetdoscover and so on (In reply to comment #17) > BTW I think that openib files needs to install newenvd also > with > ---------CUT HERE-------- > IBPATH="/usr/bin" > ---------CUT HERE-------- > > something like .etc/env.d/02openib > > This env varieble needed because it used by some scripts like ibnetdoscover and > so on > Looks fine to me. I updated the existing ebuild. (In reply to comment #16) > Thanks =) I'll gonna try this today =) > BTW I can try to make split ebuilds for 1.3.1 > may be it will be more simple then monolitic one =) > I just updated several of the split ebuilds, up to the latest versions I could find on openfabrics.org/downloads. (In reply to comment #19) > I just updated several of the split ebuilds, up to the latest versions I could > find on openfabrics.org/downloads. > OFED-1.3 tarbol contains srpms with soure tarbolls for now So if anybody can host this tarbolls this will be great =) (In reply to comment #20) > (In reply to comment #19) > > > I just updated several of the split ebuilds, up to the latest versions I could > > find on openfabrics.org/downloads. > > > > OFED-1.3 tarbol contains srpms with soure tarbolls for now > So if anybody can host this tarbolls this will be great =) > Its actually not so bad to extract the tarballs from SRPMS. The download of OFED-*.tgz takes a while, but it's a least a one-time download if you are installing several packages. the openib-userspace and openib-drivers ebuilds are a good examples of how to install from the SRPMS. (In reply to comment #21) > > Its actually not so bad to extract the tarballs from SRPMS. The download of > OFED-*.tgz takes a while, but it's a least a one-time download if you are > installing several packages. > the openib-userspace and openib-drivers ebuilds are a good examples of how to > install from the SRPMS. > OK =) I'll try to make split ebuilds soon Thanks Actualy already works in tree |