Re: linux-next: manual merge of the tiny tree with the tip tree

[Josh Triplett <josh@joshtriplett.org>]

On Tue, Sep 23, 2014 at 07:43:28AM +0200, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Today's linux-next merge of the tiny tree got conflicts in
> > arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
> > commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
> > copy_thread() to arch_dup_task_struct()") and 6f46b3aef003 ("x86:
> > copy_thread: Don't nullify ->ptrace_bps twice") from the tip tree and
> > commits a1cf09f93e66 ("x86: process: Unify 32-bit and 64-bit
> > copy_thread I/O bitmap handling") and e4a191d1e05b ("x86: Support
> > compiling out userspace I/O (iopl and ioperm)") from the tiny tree.
> 
> Why are such changes in the 'tiny' tree? These are sensitive 
> arch/x86 files, and any unification and compilation-out support 
> patches need to go through the proper review channels and be 
> merged upstream via the x86 tree if accepted...
> 
> In particular the graticious sprinking of #ifdef 
> CONFIG_X86_IOPORTs around x86 code looks ugly.
> 
> Josh, don't do that, this route is really unacceptable. Please 
> resubmit the latest patches and remove these from linux-next.

I'd previously submitted these patches for review; the last round of
feedback seemed entirely positive (with some explicit acks) on the 32/64
unification patches, and generally positive on the last patch of the
series (apart from a misunderstanding about this being configurable but
still default y).  I CCed you on that submission, and hadn't seen any of
this feedback from you at that time (nor a suggestion of which tree this
should go through).  My intention with adding these patches to tiny/next
tree was purely for an integration check with -next, and I'd planned to
resend these by email shortly for an additional round of review with an
explicit question of what route they should take into the kernel.

I've dropped tiny/no-io from tiny/next; I'll poke at it further and
resubmit for the x86 tree later, likely not for the next merge window at
this point.

Thanks for the feedback on process; this is day 1 of having a
merge-window-bound tree in -next for the first time. :)

- Josh Triplett