Apparently, On Thu, Mar 14, 2002 at 03:01:16PM -0500,
Andrew R. Reiter said words to the effect of;
> On Thu, 14 Mar 2002, Jake Burkholder wrote:
>
> :> :Can you explain the wierd logic that was added to linker_file_unload?
> :>
> :> Ugh, yes, this is kinda ugly. Essentially this is a result of hacking
> :> this back and forth between where we should be holding SLOCK over. This
> :> is exactly what I wanted to discuss this b/c prior to making this change,
> :> I had a much more simple strategy here (but was dropped due to changes to
> :> a better strategy for kern_module). We discussed before about possibly
> :> having two sets of lookup functions -- internal and external -- perhaps
> :> this is a better solution?
> :
> :Hmm, I'll have to look at it more closely.
> :
> :>
> :> :Thanks,
> :> :Jake
>
> I uploaded a new patch (tested somewhat) to:
> http://people.freebsd.org/~arr/modlock.diff
>
> this takes care of 2 of the 3 issues you brought up -- but, I'd enjoy
> inspection of the atomic set and addcalls I used.
Sorry, I should have been clearer. module_lookupbyname should assert that
the lock is locked either shared or exclusive, sx_assert(SX_LOCKED) does
this, so it can be called with either. Don't bother with the shared lock -
upgrade - release exclusive, or with the atomic ops, just get an exclusive
lock over the whole thing.
like:
MOD_XLOCK;
mp = module_lookupbyname(newmod->name);
if (mp != NULL) {
MOD_XUNLOCK;
...
return (EEXIST);
}
newmod->id = nextid++;
TAILQ_INSERT_TAIL(&modules, newmod, link);
....
MOD_XUNLOCK;
return (0);
>
> I'll relook at the 3rd issue (ugliness in kern_linker) and see what I can
> figure out if I don't hear from you.
Ok.
Jake
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message