On Mon, Oct 28, 2002 at 11:47:00AM -0800, Matthew Dobson wrote:
> Hmmm... MAX_NR_NODES is *definitely* available in the non-discontig
> case. In include/linux/param.h, MAX_NR_NODES (ifndef'd) is defined to
> be 1.
I missed this bit.
> > That is why arm has asm/memory.h to contain everything related to memory
> > translation and discontig memory.
> This isn't *just* a discontig change. CONFIG_DISCONTIGMEM is a
> convenient option to key off of, but as the kernel becomes more and more
> NUMA aware, the number of nodes in the system becomes a useful bit of
> information to more and more of the code. *That* is why (along with a
> suggestion from wli) I put the #defines in param.h.
To me, it seems inappropriate to litter header files that contain
nothing to do with memory management with stuff from memory management
when other headers that already contain memory management bits get
ignored. This type of practice is why we've ended up with #include
hell in the kernel today.
> > It would be better if it remained in mmzone.h for non-arm, and the
> > memory.h files for arm. I really never understood why numnodes.h was
> > created when mmzone.h has works adequately well since 2.3.
>
> As mentioned in the original post, I was trying
> to kill a bunch of (seemingly) unnecessary .h files (the numnodes.h's
> specifically), and remove the MAX_[NUM|NR_]NODES duality. If that can't
> be accomplished, then all this would do is move the confusion around,
> and I don't want that...
I'm in agreement with you here.
> If you feel param.h is the wrong place, I originally had the #define's
> in asm/topology.h.
This seems like a good solution - linux/mmzone.h already includes this
file, so it wouldn't be adding all that much to the #include hell.
Also, asm-generic/topology.h contains stuff to do with numa/discontig
already, so it seems perfect.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:39 EST