Re: Where did vm_operations_struct->unmap in 2.4.0 go?

[David Woodhouse <dwmw2@infradead.org>]

kaos@ocs.com.au said:
> So you want two services, one static for code that does not do any
> initialisation and one dynamic for code that does do initialisation.
> Can you imagine the fun when somebody adds startup code to a routine
> that was using static registration? 

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 
maintain.

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
Makefile."

kaos@ocs.com.au said:
> 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 :)

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/