On Sat, Mar 10, 2018 at 02:08:43PM +0000, Luis R. Rodriguez wrote: > The alternative to this would be a simple equivalent of try_then_request_module() > for UMH modules: try_umhm_then_request_umh_module() or whatever. So just as I > argued earlier over UMH limitations, this is not the end of the world for umh > modules, and it doesn't mean you can't get *properly* add umh modules upstream, > it would *just mean* we'd be perpetuating today's (IMHO) horrible and loose > semantics. I was about to suggest that perhaps a try_umhm_then_request_umh_module() or whatever should not be a macro -- but instead an actual routine, and we don't export say the simple form to avoid non-deterministic uses of it from the start... but the thing is *it'd have to be a macro* given that the *check* for the module *has to be loose*, just as try_then_request_module()... *Ugh* gross. Another reason for me to want an actual deterministic clean proper solution from the start. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
