[Devel] Re: [PATCH 01/29] task containersv11 basic task container framework
Andrew Morton
akpm at linux-foundation.org
Sun Sep 30 02:03:30 PDT 2007
On Sun, 30 Sep 2007 00:10:18 -0700 "Paul Menage" <menage at google.com> wrote:
> On 9/29/07, Paul Jackson <pj at sgi.com> wrote:
> > Paul M:
> >
> > This patch doesn't build for me in the following case. If I apply the
> > rest of the containersv11 patches, it builds, but if I happen to bisect
> > into this set of patches having applied only:
>
> These patches weren't the normal style of incremental patchset - they
> were direct substitutions of the previous patches in Andrew's -mm
> tree.
>
> Andrew's approach when encountering patches that are, e.g. missing
> includes on some architectures, is to add a *-fix.patch to the series;
> in this case it looks as though the fix for the missing ia64 include
> was added towards the end of the series rather than directly after the
> patch that needed it.
It makes my poor little life heaps easier if people can refer to patches
via their original Subject: or, better, their filename in the -mm patch
series.
I have vague memories that one of the container/cgroup fixup patches was a
bit of a jumbo patch which intersected multiple preceding patches. Often I
will refactor such a patch into several little *-fix.patch patches so that
everything lands nicely, but this time it was all too much effort and I
just jammmed <whichever patch it was> onto the tail of the queue.
And I think that's OK, because we don't care about git bisectability with
CONFIG_CGROUPS=y (I think?) Anyone who is bisecting through the middle of
the containers patch series is not searching for a containers problem, so
they can just configure it all off.
If we broke the build when CONFIG_CGROUPS=n then yeah, that's a problem.
wrt Paul's observation:
> ... also ... too bad the names of these patches all have 'container' in
> them, not 'cgroup'. I realize how this came to be, due to changing
> container to cgroup after these patches were named, but it sure would
> be nice if the final patch set record that gets layed down in Linus's
> history showed the correct name of 'cgroup' in these patch names.
that'll be OK. The "task-containers" text appears only in the filenmaes in
the -mm patch series. Those filenames don't make an appearance in the git
tree at all, so I didn't bother renaming all the files.
> Hence the fact that you couldn't compile until
> that later patch had been pushed.
>
> Andrew, is it practical for you to collapse any *-fix.patch files for
> cgroups into the appropriate patches that they fix? That would
> simplify the patch set a bit.
Yep, I always do that prior to sending to Linus, so everything hits the git
tree as nicely as possible.
I normally defer that patch-folding exercise until the last minute, but I
will occasionally do a big fold-some-patches-together pass, just to reduce
the plain number of patches which I'm carrying. It gets irritating when
this:
box:/usr/src/25> grep foo patches/*
zsh: argument list too long: grep
happens.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list