Karl Feind wrote:
Clearly, we need to agree on a conventional way that a uDAPL
layer can register itself in /etc/dat.conf when it gets installed and
unregister itself when it gets uninstalled. Furthermore, upgrading
one uDAPL should not have adverse effects on other uDAPLs. I don't
see how this can be done with the current RPM structure.
Thanks for any guidance.
I can look into improving the RPM install and uninstall but we will have
to make alot of assumptions about naming conventions. As long as the
provider names for OFED are unique (OpenIB), and we can figure out how
to do this in the rpm, maybe something like:
For install:
# if exists then remove any existing OFED entry and append new OFED
entries, no comments
if [ -e /etc/dat.conf ]
then
sed -e "/OpenIB/d" < /etc/dat.conf > /tmp/$$ofed_dat_create
mv /tmp/$$ofed_dat_create /etc/dat.conf
sed -e "/#/d" < doc/dat.conf >> /etc/dat.conf
else
cp doc/dat.conf /etc/dat.conf
fi
For uninstall:
# if OFED is only provider installed then remove dat.conf, otherwise
just remove OFED entries
sed -e "/OpenIB/d" -e "/#/d" < /etc/dat.conf > /tmp/$$ofed_dat_clean
if [ 'wc -w /tmp/$$ofed_dat_clean' == 0 ]
then
rm /etc/dat.conf
else
sed -e "/OpenIB/d" < /etc/dat.conf > /tmp/$$ofed_dat
mv /tmp/$$ofed_dat /etc/dat.conf
fi
comments? other suggestions?
-arlin
_______________________________________________
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
