Messages in this thread | | | Subject | Re: simple handling of module removals Re: [OKS] Module removal | From | Daniel Gryniewicz <> | Date | 08 Jul 2002 11:48:19 -0400 |
| |
Okay, maybe this is a bit naive, but isn't this problem already solved? Couldn't we just put a read/write lock on the module, where using is reading, and removing is writing? As I understand it, this should impose little overhead on the use (read) case, and ensure that, when a context has the remove (write) lock there are no no users (readers) and cannot be any?
Daniel
On Mon, 2002-07-08 at 09:58, Thunder from the hill wrote: > Hi, > > Still, we shouldn't lock everything. I could do awful lots of interesting > things while the only thing that is being done is to remove a module. It > doesn't make sense IMO to lock things that are completely unrelated to > modules. > > And BTW, what's so much of an overhead if we tell everyone who tries to > mess around with a certain module that he'd better wait until we unloaded > it? It could be done like your schedule hack, but cleaner in that respect > that those who got nothing to do with the module can keep on running. > > > Good point. Member usecount could be anything. A 'long' isn't the > > correct pad for all types, but it will probably handle everything that > > was intended. > > But as I mentioned - atomic_t is changed (e.g. to long long) -> > module->pad blows up, because the sizeof(struct module) is different, > depending on which part of the union we're using. > > 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------
-- Recursion n.: See Recursion. -- Random Shack Data Processing Dictionary
- 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/
| |