Re: Some guidance/suggestion please

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jan 14,  9:11, Paul Goyette wrote:
}
} I'm looking into more modularization of the kernel, and my next
} "target" is the ALTQ stuff.  Right now, there are several network
} device drivers that are built as loadable modules, yet they still
} depend on conditional compilation.  In particular, there seems to
} be some number of code fragments similar to
} 
}  	...
}  	#ifdef ALTQ
}  		altq-code-part-A
}  	#endif
}  		(common code)
}  	#ifdef ALTQ
}  		altq-code-part-B
}  	#endif
}  	...
} 
} The existing module_hook mechanism doesn't help us here.  We can
} make the two pieces of altq code into module hooks, but that
} doesn't handle the case where the module gets loaded or unloaded
} between the two parts of the altq code.
} 
} We have the module_hold()/module_rele() mechanism but they're not
} really appropriate here.  Both routines require us to already have
} access to the module's data in its struct module.
} 
} So, I'm pretty sure we need a new mechanism, one that prevents a
} module from being unloaded during critical sequences.  This new

     Unload is a request that goes to the module.  It is the modules
responsibility to deny the request if it can't be safely unloaded.
This has always been the case.  I don't think a new mechanism is
requried here.

} mechanism needs to also prevent a module from being newly loaded
} (or at least, from installing any new hooks);  otherwise we could
} potentially execute the part-B code without have run any part-A
} code on which part-B might depend.  Therefore the mechanism cannot
} live within the module itself.

     This one is more tricky.  The module can certainly error out
in the load routine and refuse to load.  The problem is that the
calls to "part A" and "part B" are external to the module.  How
does it know that the dummy "part A" has been called, but not the
dummy "part B"?

     There are a couple of possibilities here, all bad.  The dummy
"part A" could set a flag which is cleared by the dummy "part B".
The module could then refuse to load if the flag is set.  The other
possibility is that the module could simply clear the flag and
return when "part B" is called.

     The problem here is what happens if multiple devices are
calling AltQ at the same time?  The best situatiion I can see is
that the module be written in such a way that if "part B" is called
without "part A" being called that it not cause problems.  This
should be the case anyways to have resiliency against a broken
driver calls "part B" without calling "part A".

} FWIW, I vaguely remember having one or two instances of this issue
} during my work on the compat modules (some years ago).  I think I
} addressed these by making explicit checks on the hook->hooked
} member, but that's not really correct.  (Unfortunately I can't
} remember any details on this...)
} 
}-- End of excerpt from Paul Goyette