[lkml]   [2001]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Where did vm_operations_struct->unmap in 2.4.0 go?
Date 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

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." 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 :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.083 / U:2.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site