On Sat, Jan 13, 2001 at 12:11:31PM +1100, [EMAIL PROTECTED] wrote:
> My apologies. I read the patch, not the full source code and the patch
> does not have enough programming context to show that the driver is
> only searching its own symbol space. In my own defense, the references
> to spinlock_t unload_lock and MOD_CAN_QUERY(mp) in the patch are highly
> misleading, those statements only make sense when you are looking at a
> symbol table for another module. When searching your own symbol table
> the current module must be live with a non-zero use count, not being
> unloaded and it can always be queried.
>
> >Contrary to what you're saying, the patch does not just inline the old
> >get_module_symbol algorithm nor does it access any of module.c's internal
> >data.
>
> unload_lock and MOD_CAN_QUERY were copied verbatim from the old
> get_module_symbol, even though they are completely unnecessary. That
> looks like inlining the old algorithm to me.
>
> struct module_symbol, mp->nsyms and mp->syms are module.c internal
> data. If it is ever necessary to change those structures, nothing
> outside module.c, the 32/64 handlers for module system calls and
> modutils should be affected. Now if I change module_symbol, other bits
> of the kernel will unexpectedly break, this is not good.
I see what you mean. What do you suggest should be done in the context of
the driver? As you can easily tell, I'm not overly familiar with the
internal workings of the kernel. That and the mere impossibility to get
any kind of help at the mere mention of the Nvidia driver module ("go bitch
at nvidia", "who cares", ...) do not exactly make it easier to fix problems
that arise from changes to the kernel.
--
----------------------------------------------------------------------
christian zander we come to bury dos, not to praise it.
[EMAIL PROTECTED] -- paul vojta
----------------------------------------------------------------------
PGP signature
