Jason Rennie <[EMAIL PROTECTED]> writes: > On 4/23/05, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> I *think* I might understand more about what's going on, but I'm not >> sure. As near as I can tell, 1.2.13 OpenAFS packages did add the .mp >> to the init script, but the 1.3.81 packages don't. That means that if >> you try to use the 1.3.81 openafs-client package with modules built >> from 1.2.13, you get this problem on SMP systems. > Yes. I think that's exactly what happened. But, since Debian sarge > does not include compiled openafs-modules, the use of 1.2.13 modules w/ > 1.3.81 client was a natural result of a dist-upgrade. I looked at this some more. The change in the init script is that in 1.2.13 and earlier, the $MP variable is used to set LIBAFS and LIBAFS is used with insmod. In 1.3.x, LIBAFS is set to openafs.*o. The wildcard is intended to pick up .ko, I'm guessing, but it would also pick up openafs.mp.o. I'm not sure that was intentional. (If both .o and .mp.o versions are present, it looks like it might even cause a syntax error in the shell script.) Anyway, LIBAFS is only used to make sure the module is present. Similarly, modprobe loads only the openafs module. There is a corresponding change to the makefile to not add the .mp extension to the module when built. Tightening the dependencies would work, although I'm not quite sure how to do that cleanly, since openafs-client depends on the installed modules via the virtual package openafs-modules2. I think that to tighten the dependencies, we'd have to introduce a new virtual package openafs-modules3 that's provided by the new kernel modules, since I don't believe one can create versioned dependencies on virtual packages. That's kind of a hassle. The other option would be to modify the init script so that if an openafs.mp.* module is present, it will fall back on the old logic (although will keep using modprobe) and use $MP as appropriate. This should keep it working with modules generated by the old source package. My inclination is to go with the latter. Sam, do you have a feeling on this? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
