Hi,
On Mon, 8 Jul 2002, Richard B. Johnson wrote:
> (3) Set a global flag "module_remove", it doesn't have to be atomic.
> It needs only to be volatile. It is used in schedule() to trap
> all CPUs.
> schedule()
> {
> while(module_remove)
> ;
> }
That doesn't sound too clean to me...
Maybe we should lock that module explicitly, instead of halting anything
that is schedule()d.
We should possibly add something to lock in struct module (or
module_info), be it some kind of integer or be it a semaphore (which is
clearly a bit too much, I think) or a spinlock, or whatever. This
shouldn't protect the module from being used in parallel, but from being
used in removal. So on removal, we do something like module->remove |= 1
or even up(module->m_sem), and when we're done, we do something related to
undo the up, remove or whatever...
BTW, looking at struct module, we have this union
union {
atomic_t usecount;
long pad;
}
Fair enough, but if long pad is to pad (as it name tells us), shouldn't it
be atomic_t then (I mean, what if we change the type for atomic_t)?
Regards,
Thunder
-- (Use http://www.ebb.org/ungeek if you can't decode) ------BEGIN GEEK CODE BLOCK------ Version: 3.12 GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$ N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G e++++ h* r--- y- ------END GEEK CODE BLOCK------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:12 EST