> fixing this is on my todo list.

thanks!

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

On Sun, 30 Sep 2007 00:10:18 -0700 "Paul Menage" <menage@google.com> wrote:

> On 9/29/07, Paul Jackson <pj@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@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Andrew wrote:
> 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.

Ok - I guess.

In *-mm, this seems fine.  I'd have figured that in Linus's tree, a wider
variety of people will be bisecting, some of them with CONFIG_CGROUPS=y
who don't even know what a CGROUP is, and so we'd want bisect to work
for them.

But you (Andrew) would know better than I.

> 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.

Ah - ok - good.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

On Sun, 30 Sep 2007 02:15:36 -0700 Paul Jackson <pj@sgi.com> wrote:

> Andrew wrote:
> > 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.
> 
> Ok - I guess.
> 
> In *-mm, this seems fine.  I'd have figured that in Linus's tree, a wider
> variety of people will be bisecting, some of them with CONFIG_CGROUPS=y
> who don't even know what a CGROUP is, and so we'd want bisect to work
> for them.

Well obviously the situation is less than ideal, but it's livable with.

If one of their bisection points precedes the crgroups patch series,
their `make oldconfig' will knock out cgroups for them anyway, so when
their bisection cursor moves within or after the cgroups patches, they'll
still have CONFIG_CGROUPS=n.  Serendipity.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Andrew wrote:
> so when
> their bisection cursor moves within or after the cgroups patches, they'll
> still have CONFIG_CGROUPS=n.  Serendipity.

Unless it's one of the configs that enables cgroups by default, thanks
to the patch:

  task-containers-enable-containers-by-default-in-some-configs.patch

namely configs:

 arch/ia64/configs/sn2_defconfig          |    1 +
 arch/mips/configs/ip27_defconfig         |    1 +
 arch/mips/configs/sb1250-swarm_defconfig |    1 +
 arch/powerpc/configs/cell_defconfig      |    1 +
 arch/powerpc/configs/ppc64_defconfig     |    1 +
 arch/powerpc/configs/pseries_defconfig   |    1 +

But these are not commonly used configs, so that's not a big deal.

So ... yeah ... good enough.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers