From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 12 Sep 2006 13:11:44 +1000 Message-ID: <878xkpaidr.wl%peterc@quokka.chubb.wattle.id.au> From: Peter Chubb In-Reply-To: References: <45061F16.202@yahoo.com.au> <87bqplaiok.wl%peterc@quokka.chubb.wattle.id.au> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Subject: Re: A solution for more GFP_xx flags? Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Peter Chubb , Nick Piggin , linux-mm@kvack.org List-ID: >>>>> "Christoph" == Christoph Lameter writes: Christoph> On Tue, 12 Sep 2006, Peter Chubb wrote: >> Dunno about you, but the thought of passing structs around on the >> stack gives me the heebie jeebies, especially if they're going to >> be more than a word or so big. Christoph> Right. >> Either pass by reference, or separate out the args, so it's >> explicit how much info's being copied around. Christoph> Maybe I misunderstood Nick but I did not think he was Christoph> proposing pushing structs on the stack. Maybe I misunderstood you: Christoph> We could define a structure Christoph> struct allocation_control { Christoph> unsigned long flags; /* Traditional flags */ Christoph> int node; Christoph> struct cpuset_context *cpuset; Christoph> struct mempol *mpol; Christoph> }; Christoph>We could define struct constants called GFP_KERNEL and GFP_ATOMIC. Christoph> const struct allocation_control gfp_kernel { Christoph> GFP_KERNEL, -1, NULL, NULL Christoph> } Christoph> And then do Christoph> alloc_pages(n, gfp_kernel) Did you mean alloc_pages(n, &gfp_kernel) ?? -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org