[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201409242044.GFJ81269.FJFVQOLSHtFMOO@I-love.SAKURA.ne.jp>
Date: Wed, 24 Sep 2014 20:44:43 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: lizefan@...wei.com, peterz@...radead.org, mingo@...nel.org
Cc: tj@...nel.org, miaox@...fujitsu.com, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, keescook@...omium.org
Subject: Re: [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags
Zefan Li wrote:
> Those macros make the code easier to read, and emacs and cscope can also
> understand them.
I'm using legacy LXR which cannot understand them. But
> I'd vote for this:
>
> TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
> TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)
>
> TASK_PFA_TEST(SPREAD_PAGE, spread_page)
> TASK_PFA_SET(SPREAD_PAGE, spread_page)
> TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)
>
> TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
> TASK_PFA_SET(SPREAD_SLAB, spread_slab)
> TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)
>
> over this:
you can go ahead. This difference is not a stopper.
Tejun Heo wrote:
> All the patches look good to me. I can't say I'm a big fan of
> function defining macros but I don't have prettier alternatives
> either. Once Peter/Ingo acks the patches, I'll route them through
> cgroup/for-3.17-fixes.
Peter and Ingo, are these patches OK for you?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists