linux-kernel - Re: [PATCH 72/79] sysdev: Pass the attribute to the low level sysdev show/store function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Jul 2008 11:03:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Greg KH <gregkh@...e.de>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, andi@...stfloor.org,
	ak@...ux.intel.com, tiwai@...e.de,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-next@...r.kernel.org
Subject: Re: [PATCH 72/79] sysdev: Pass the attribute to the low level
	sysdev show/store function

* Greg KH <gregkh@...e.de> wrote:

> On Wed, Jul 23, 2008 at 01:04:35PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > On Tue, 22 Jul 2008 14:19:19 -0700 Greg KH <gregkh@...e.de> wrote:
[...]
> > > * Andrew Morton <akpm@...ux-foundation.org> wrote:
> > >
> > > > This wrecks use-sysdev_class-in-schedc.patch (below), which I 
> > > > merged a week ago and will now drop.
> > > >
> > > > Why did this patch from Andi just turn up in linux-next now, 
> > > > halfway through the merge window?  It has a commit date of July 
> > > > 1 yet it has never before been sighted in linux-next.
[...]
> > >
> > > Andi any thoughts?
> > 
> > The patch
> > (sysdev-pass-the-attribute-to-the-low-level-sysdev-show-store-function.patch)
> > has existed in the driver-core part of linux-next since July 4, but the
> > kernel/sched.c part only got added yesterday.
> 
> That came from the updated version that Andi sent me to fix the 
> sparc64 build problems the original version had.
> 
> Stephen, thanks for diging this out.

ok, lemme do a bit of merge window flaming here, in defense of Andrew.

This commit history:

  commit 4a0b2b4dbe1335b8b9886ba3dc85a145d5d938ed
  Author:     Andi Kleen <andi@...stfloor.org>
  AuthorDate: Tue Jul 1 18:48:41 2008 +0200
  Commit:     Greg Kroah-Hartman <gregkh@...e.de>
  CommitDate: Mon Jul 21 21:55:02 2008 -0700

    sysdev: Pass the attribute to the low level sysdev show/store function

  [...]

    I converted all users in tree to the new show/store prototype. It's 
    a single huge patch to avoid unbisectable sections.

    Runtime tested: x86-32, x86-64
    Compiled only: ia64, powerpc
    Not compile tested/only grep converted: sh, arm, avr32

covers a relatively trivial patch that we'd normally not notice, but it 
is ... a ... misrepresentation of the true situation on several levels:

1) The changelog. The updated patch Andi sent did not declare the other
   incremental changes (to sched.c) it also included freshly.

2) The date. This patch did not originate on Jul 1 - if Andi sent a 
   material update yesterday it should say Jul 21, not Jul 1.

3) The justification. Huge atomic patches are fine and can indeed be 
   much simpler than a gradual switchover, _iff_ they are done 
   perfectly. If there's any doubt then they are by far not the only 
   option to pursue - we've done finegrained API changeovers for years.

... which all we still wouldnt worry much about (the whole change is 
relatively trivial), if it had been done more carefully without wrecking 
Andrew's workflow in the middle of the merge window.

If every upstream pull - no matter how trivial - caused such work flow 
problems for Andrew (who is sitting at the _end_ of all linux-next stuff 
so is particularly hard hit by last-minute updates - especially if they 
are not append-only) then Andrew would never be able to get his stuff 
from -mm into -git.

If Andi cannot be bothered to do a proper finegrained workflow _or_ at 
least make it damned sure that he does not mess up other people's work 
via one huge patch modified on the last day (instead of at least sending 
an incremental patch for the last delta) then he should not be doing 
such complex changes.

Grmbl!

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/