OpenVZ Forum


Home » Mailing lists » Devel » [PATCH 00/29] Rename Containers to Control Groups
Re: [PATCH 01/29] task containersv11 basic task container framework [message #21007 is a reply to message #21003] Sun, 30 September 2007 09:03 Go to previous messageGo to previous message
akpm is currently offline  akpm
Messages: 224
Registered: March 2007
Senior Member
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
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [PATCH] Update get_net_ns_by_pid
Next Topic: [RFC}[PATCH] forced uncharge for successful rmdir.
Goto Forum:
  


Current Time: Wed Aug 20 04:58:08 GMT 2025

Total time taken to generate the page: 0.08703 seconds