Re: simple handling of module removals Re: [OKS] Module removal

Thunder from the hill
2002-07-08T12:40:31Z

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------