From: Aleksa Sarai <cyphar@cyphar.com>
To: Tejun Heo <tj@kernel.org>
Cc: lizefan@huawei.com, mingo@redhat.com, peterz@infradead.org,
richard@nod.at, "Frédéric Weisbecker" <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH v9 3/4] cgroups: allow a cgroup subsystem to reject a fork
Date: Sat, 18 Apr 2015 06:48:55 +1000 [thread overview]
Message-ID: <CAOviyah2dBbc5MecxzCfOt36dVfCaN7F7u+5ycPmp3eVDc_J2Q@mail.gmail.com> (raw)
In-Reply-To: <20150417204206.GI16743@htj.duckdns.org>
>> >> Do you also want me to completely drop the COUNT macro? IMO it makes
>> >> the CGROUP_<TAG>_COUNT consolidation much nicer.
>> >
>> > What's wrong with simply having start and end tags?
>>
>> Because you'd have to write (CGROUP_TAG_END - CGROUP_TAG_START) every
>> time? It's a small addition and it makes referencing the range of a
>> tagged section much easier.
>
> Wouldn't loops look more like
>
> for (subsys = CGROUP_TAG_START; subsys < CGROUP_TAG_END; subsys++)
Sorry, I meant for defining arrays. `state[CGROUP_TAG_END -
CGROUP_TAG_START]` is just more annoying to type and read than
`state[CGROUP_TAG_COUNT]`.
> And even if not, just define a separate macro for the length. It's
> not like we're gonna have a lot of tags.
Do you mean like this?
#define SUBSYS_TAG_COUNT(_tag) (CGROUP_ ## _tag ## _END - CGROUP_ ##
_tag ## _START)
That's fine I guess, I just wanted to match CGROUP_SUBSYS_COUNT in
semantics, but I'll do that if you prefer it that way.
--
Aleksa Sarai (cyphar)
www.cyphar.com
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar-gVpy/LI/lHzQT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
richard-/L3Ra7n9ekc@public.gmane.org,
"Frédéric Weisbecker"
<fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v9 3/4] cgroups: allow a cgroup subsystem to reject a fork
Date: Sat, 18 Apr 2015 06:48:55 +1000 [thread overview]
Message-ID: <CAOviyah2dBbc5MecxzCfOt36dVfCaN7F7u+5ycPmp3eVDc_J2Q@mail.gmail.com> (raw)
In-Reply-To: <20150417204206.GI16743-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
>> >> Do you also want me to completely drop the COUNT macro? IMO it makes
>> >> the CGROUP_<TAG>_COUNT consolidation much nicer.
>> >
>> > What's wrong with simply having start and end tags?
>>
>> Because you'd have to write (CGROUP_TAG_END - CGROUP_TAG_START) every
>> time? It's a small addition and it makes referencing the range of a
>> tagged section much easier.
>
> Wouldn't loops look more like
>
> for (subsys = CGROUP_TAG_START; subsys < CGROUP_TAG_END; subsys++)
Sorry, I meant for defining arrays. `state[CGROUP_TAG_END -
CGROUP_TAG_START]` is just more annoying to type and read than
`state[CGROUP_TAG_COUNT]`.
> And even if not, just define a separate macro for the length. It's
> not like we're gonna have a lot of tags.
Do you mean like this?
#define SUBSYS_TAG_COUNT(_tag) (CGROUP_ ## _tag ## _END - CGROUP_ ##
_tag ## _START)
That's fine I guess, I just wanted to match CGROUP_SUBSYS_COUNT in
semantics, but I'll do that if you prefer it that way.
--
Aleksa Sarai (cyphar)
www.cyphar.com
next prev parent reply other threads:[~2015-04-17 20:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-12 0:51 [PATCH v9 0/4] cgroups: add pids subsystem Aleksa Sarai
2015-04-12 0:51 ` Aleksa Sarai
2015-04-12 0:51 ` [PATCH v9 1/4] cgroups: use bitmask to filter for_each_subsys Aleksa Sarai
2015-04-12 0:51 ` Aleksa Sarai
2015-04-12 0:51 ` [PATCH v9 2/4] cgroups: replace explicit ss_mask checking with for_each_subsys_which Aleksa Sarai
2015-04-12 0:51 ` [PATCH v9 3/4] cgroups: allow a cgroup subsystem to reject a fork Aleksa Sarai
2015-04-12 0:51 ` Aleksa Sarai
2015-04-13 14:24 ` Tejun Heo
2015-04-13 14:24 ` Tejun Heo
2015-04-14 0:33 ` Aleksa Sarai
2015-04-14 12:17 ` Tejun Heo
2015-04-14 12:17 ` Tejun Heo
2015-04-16 13:57 ` Aleksa Sarai
2015-04-16 13:57 ` Aleksa Sarai
2015-04-17 14:45 ` Tejun Heo
2015-04-17 14:45 ` Tejun Heo
2015-04-17 20:35 ` Aleksa Sarai
2015-04-17 20:35 ` Aleksa Sarai
2015-04-17 20:42 ` Tejun Heo
2015-04-17 20:48 ` Aleksa Sarai [this message]
2015-04-17 20:48 ` Aleksa Sarai
2015-04-17 20:55 ` Tejun Heo
2015-04-17 20:55 ` Tejun Heo
2015-04-17 21:06 ` Aleksa Sarai
2015-04-17 21:06 ` Aleksa Sarai
2015-04-12 0:51 ` [PATCH v9 4/4] cgroups: implement the PIDs subsystem Aleksa Sarai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOviyah2dBbc5MecxzCfOt36dVfCaN7F7u+5ycPmp3eVDc_J2Q@mail.gmail.com \
--to=cyphar@cyphar.com \
--cc=cgroups@vger.kernel.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=richard@nod.at \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.