Re: 2.6.5-rc2-aa1

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Mar 22, 2004 at 02:31:15PM +0000, Hugh Dickins wrote:
> On Mon, 22 Mar 2004, Andrea Arcangeli wrote:
> > On Mon, Mar 22, 2004 at 09:07:54AM -0500, Rik van Riel wrote:
> > > 
> > > Most people seem to be talking about "pte based rmap" vs
> > > "object based rmap".  So far you're the only one who I've
> > > seen using "rmap" to mean just "pte based rmap" and not
> > > also "object based rmap".
> > 
> > then I'm the only one and I could have been biased because rmap.c is
> > including 99% of code for the pte based rmap, and my objrmap.c is including
> > 99% of code for the objrect based _reverse_mappings_, still objrmap.c is
> > a more appropriate name for that stuff IMO (especially if somebody else
> > is mistaken as I am using the word rmap to mean the current 2.6 code in
> > mm/rmap.c).
> 
> I agree with Rik and Christoph (I agreed with all of Christoph's points,
> but most can be left until later on): mm/rmap.c and include/linux/rmap.h
> (the latter a name change from include/linux/rmap-locking.h).
> 
> objrmap is the particular implementation found within that file in your
> tree, but Rik imagined right from the start that there would be various
> implementations:
> 
>  * This is kept modular because we may want to experiment
>  * with object-based reverse mapping schemes.
> 
> (Aaargh, now we can expect someone to propose
> CONFIG_PTE_CHAIN_RMAP, CONFIG_ANON_VMA_RMAP, CONFIG_ANONMM_RMAP etc)

obviously I read that comment, but I definitely hope he meant people
adding objrmap.c w/o necessairly deleting rmap.c too like me and you did
(i.e. we don't provide a CONFIG_RMAP to go back), and to have the
CONFIG_ in a Makefile _definitely_not_ in rmap.c mixing everything
unrelated in the same file.

Separating the entry points from the rest of the mm/*.c is sure a good
idea, and infact I left those separated in objrmap.c, like they were
separated in rmap.c, so you can go ahead and add an anobjrmap.c and we
can have a CONFIG_ option to select if to compile with objrmap.c or with
anobjrmap.c.

your example of having multiple methods in the same tree selectable as a
config option is the very best example where keeping the objrmap.c code
separated from the rmap.c code in two different files is a MUST (or at
the very least a SHOULD to avoid a mess of #ifdefs in the middle of C
code since there's nothing to share except the function parameters).