In the 2.5.3x kernel, what's the point of defining pte_chain_lock()
and pte_chain_unlock() in page-flags.h? These two routines make it
impossible to include page-flags.h on it's own, because they require
"struct page" to be defined (and a forward declaration isn't
sufficient either). This can introduce rather annoying circular
include-file dependencies.
--david
David Mosberger wrote:
>
> In the 2.5.3x kernel, what's the point of defining pte_chain_lock()
> and pte_chain_unlock() in page-flags.h? These two routines make it
> impossible to include page-flags.h on it's own, because they require
> "struct page" to be defined (and a forward declaration isn't
> sufficient either). This can introduce rather annoying circular
> include-file dependencies.
It's a wart. The now-abandoned hashed spinlocking patch moves
them into <linux/rmap-locking.h>. We can do that anyway - only
two files need it.
Or maybe just put them in asm-generic/rmap.h. I'll fix it up.
On Friday 30 August 2002 08:37, Andrew Morton wrote:
> David Mosberger wrote:
> >
> > In the 2.5.3x kernel, what's the point of defining pte_chain_lock()
> > and pte_chain_unlock() in page-flags.h? These two routines make it
> > impossible to include page-flags.h on it's own, because they require
> > "struct page" to be defined (and a forward declaration isn't
> > sufficient either). This can introduce rather annoying circular
> > include-file dependencies.
>
> It's a wart. The now-abandoned hashed spinlocking patch moves
> them into <linux/rmap-locking.h>. We can do that anyway - only
> two files need it.
>
> Or maybe just put them in asm-generic/rmap.h. I'll fix it up.
Yup. As a matter of principle, headers for data should be separated from
headers for operations.
--
Daniel