Re: [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag

From: David Rientjes
Date: Tue Feb 26 2008 - 16:54:57 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/