This is really beyond the scope of openafs-info, but... On Mon, 30 Oct 2006, Peter N. Schweitzer wrote:
> Not to belabor the point, but for my understanding, the tasklist_lock > variable within the AFS module and the variable by the same name within > some parts of the kernel code (sched.c, for example) are not related, > it's just a different use of the same name, maybe for the same sort of > thing. Hence it was only necessary to persuade the compiler to actually > allocate space for the symbol within the AFS module's data section > rather than assume that the symbol would be instantiated elsewhere? No; they're the same. tasklist_lock is the lock which protects the kernel's list of tasks (processes). It's necessary to hold this lock when traversing or changing that list. In newer kernels, the means of searching the task list has changed somewhat, and that lock is no longer exported to us, so we have to do things a bit differently. What the declaration with the "weak" attribute does is cause the compiler to generate a "weak reference", which indicates that the reference is allowed to remain unsatisfied. If this happens, the linker will set the symbol's value (which, in this case, represents the address of a data structure) to zero. The patch works around what I would consider to be a compiler bug, which is that the "weak" attribute has no effect on declarations which do not have global scope. This is silly, because an 'extern' declaration has the same meaning regardless of the scope in which it appears - the only effect of using one in non-global scope is that the visibility of the name is restricted to the scope in which the declaration appears. -- Jeff _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
