lkml.org 
[lkml]   [2008]   [Feb]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 26 Feb 2008 13:54:02 -0800 (PST)
FromDavid Rientjes <>
SubjectRe: [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag
On Tue, 26 Feb 2008, Lee Schermerhorn wrote:

> > This is a natural implementation detail to accomodate your insistance that 
> > the mode and flags be passed as separate actuals throughout many of the 
> > mm/mempolicy.c functions.
> 
> [:-(]
> 

I know, I know :)

It became such an elaborate discussion here that I really didn't want the 
entire patchset, which adds a lot of power for cpuset-constrained 
applications using mempolicies, to stall on it.

I'm not opposed to adding comments in certain places or changing the name 
of an automatic variable, but that's been the degree of review that these 
patches have had.

> > It becomes rather obvious what they represent when you read the entire 
> > sys_mbind() implementation, which is serving a syscall that provides its 
> > own formal for passing flags.  The name 'mode_flags' is exactly what it 
> > is: flags for the mempolicy mode.
> 
> Not to be confused with the MPOL_MF_* flags which are MemPOLicy Mbind
> Flags passed via the flags parameter.  Nor the other MPOL_F_* flags
> which are get_mempolicy() flags, also passed via the flags arg.
> 

Notice in patch 2 of the series where I add the flags member to struct 
mempolicy:

	+	unsigned short flags;	/* See set_mempolicy() MPOL_F_* above */
I had to explicitly say they were for "set_mempolicy() MPOL_F_*" flags in 
an attempt to separate them from the various get_mempolicy() MPOL_F_* 
flags that already exist.  Instead of simply choosing a different format, 
I felt that MPOL_F_STATIC_NODES, for example, is exactly what userspace 
should use and corresponds well with the existing get_mempolicy() flags.

		David


\
 
 \ /
  Last update: 2008-02-26 22:57    [from the cache]
©2003-2008