Oh come on. If you change a module from being 'self-contained' and
registered at compile time to requiring initialisation it's hardly
unreasonable to expect you switch the registration too.
Besides, I'm not going to allow any link order dependencies into code I
maintain without them being impossible to avoid - and if anyone's thought
about the problem hard enough to convince me to accept such a change,
they'll have noticed the need to change the registration.
> Oh dear, I added init code so I have to remember to change from static
> to dynamic registration, and that affects the link order so now I have
> to tweak the Makefile.
cf. "Oh dear, I added init code but put it _after_ the registration instead
of before, so stuff blows up."
Neither of these two programmers will get their code into anything I
cf. "Oh dear, I need registration, but I have to remember that
inter_module_xxx can't do static registration so now I have to tweak the
> Stick to one method that works for all routines, dynamic registration.
It doesn't work for all routines. It introduces unnecessary brokenness -
link order dependencies - where previously there were none.
> If that imposes the occasional need for a couple of extra calls in
> some routines and for people to think about initialisation order right
> from the start then so be it, it is a small price to pay for long term
> stability and ease of maintenance.
I'm thinking about link order. If I _wasn't_ thinking about link order,
then I'd just put the lines in the 'right' order in the Makefile and put up
with it. But I'm thinking about it, and I object to it. It is absolutely
unnecessary in this case.
As far as I'm concerned, fixing the registration problems introduced by the
dynamic inter_module_register is a small price to pay for long term
stability and ease of maintenance :)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org Please read the FAQ at http://www.tux.org/lkml/