* Andrew Morton <[email protected]> wrote:
> > and it should happen in a well defined place, not be opportunistic (and
> > relatively random) like this, making it dependent on config options and
> > calling contexts.
>
> That's an unusable assertion, sorry.
>
> Initializing lockdep in the above manner guarantees that it is initialized
> before it is used. It is *much* more reliable than "try to initialize it
> before
> some piece of code which hasn't even been written yet tries to take a lock".
So I didn't like that patch because it called into lockdep in a messy way,
without
having any real knowledge about whether it's safe to do. Should lockdep ever
grow
more complex initialization, such a solution could break in subtle ways. I
prefer
clearly broken code with static dependencies over context-dependent broken code
with dynamic call ordering/dependencies.
Fortunately we don't have to apply the patch:
> The conceptual problem is that if some piece of code does spin_lock_init() or
> DEFINE_SPINLOCK(), that lock isn't necessarily initialized yet.
The conceptual problem is that the data structures are not build time
initialized
- but the hlist conversion patch solves that problem nicely!
So I'm a happy camper.
Thanks,
Ingo
