Messages in this thread | | | From | cce3@cornell ... | Date | Thu, 1 Jul 1999 13:40:50 -0400 (EDT) | Subject | Re: tasklist_lock location |
| |
So, another question -- WHY isn't tasklist_lock exported to modules? If a module were to iterate through all the tasks, wouldn't it need to use read_(un)lock(tasklist_lock)? Or should I just loop through the tasks without locking? I don't want to cause any problems with SMP mahcines here.
again, please CC to me. thanks.
c. chris erway
On Thu, 1 Jul 1999, Steve Dodd wrote:
> I've just woken up, so I might be about to talk crap, but: > > On UP, rwlock_t (which is what tasklist_lock is) is an empty structure, i.e. > it takes no space. The macros that use it - {read,write}_{,un}lock - don't do > anything on UP[1]. When compiled for SMP, the lock exists and the macros > operate on it. AFAICS, tasklist_lock is not exported from the kernel anywhere > - there needs to be an > > EXPORT_SYMBOL(tasklist_lock) > > somewhere for it to be visible from modules. > > I guess you need to submit a patch that adds that to the appropriate section > of kernel/ksyms.c if you want your module to work with stock kernels. Otherwise, > just add it to your local kernel. > > S. > > [1] As of 2.3.8ish, the macros reference the empty structure on UP even though > they don't do anything, to avoid 'unused variable' messages. So your module > won't work on UP either for 2.3.8+.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |