Message-Id: <200809211845.42990.david-b@pacbell.net>
Date:	Sun, 21 Sep 2008 18:45:42 -0700
From:	David Brownell <david-b@...bell.net>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Felipe Balbi <felipe.balbi@...ia.com>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Tony Lindgren <tony@...mide.com>,
	Wim Van Sebroeck <wim@...ana.be>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"George G. Davis" <gdavis@...sta.com>
Subject: Re: [PATCH 3/5] watchdog: cleanup a bit omap_wdt.c

On Saturday 20 September 2008, Russell King - ARM Linux wrote:
> On Sat, Sep 20, 2008 at 10:18:41AM -0700, David Brownell wrote:
>
> > Yet i_private gets set up *somewhere* else that field wouldn't exist.
> > Look around; you'll see it gets used.  (My quick grep started in the
> > USB tree, where it turns out both usbfs and gadgetfs use it.)
> 
> Both of which are filesystems which have more control over the lifetime
> of the inode.  Device drivers don't have such luxuries.

Both of them are the *kernel part* of a *user mode device driver* ...
but regardless, that doesn't invalidate what I said (and showed!)
about how easy it is to initialize that (even in this watchdog case).


> Well, are you going to manufacture a patch to update all the watchdog
> drivers to use your new i_private method,

If Alan Cox hadn't reminded us about pending cleanups to create more
of a real watchdog framework, I might well have done so.  The core
update was trivial; driver updates could trickle in when convenient.
No "flag day" needed.  But as I noted:  Not part of this patch series.


> > > We're into the third day on this one driver.  If every OMAP driver
> > > takes this long ...
> > 
> > That seems like a strange way to account things.  It  presumes
> > that the only time review comments should be accepted is within
> > a day of the patch getting posted.  Regardless of whether the
> > reviewer has time at that point.
> 
> You define accounting for things in real time as "strange" - lol.  Your
> following sentences don't follow either.

Redefining my words doesn't help, unless you're intent on creating
arguments instead of consensus.

Review rarely happens all at once, unless very few people look at
the code.  Discouraging review is *extremely* strange.  Most developers
want loads more than they ever get.  Yet you complained about me
not reviewing at the same time you did (I happened to be traveling)
despite there being no rush to queue this.  Also strange.


> My point is that we currently have a BIG problem, and that is the OMAP
> fork being so far out of line with mainline, it isn't funny.

I call it a "branch" myself; "fork" sounds confrontational.

When more of the arch/arm/* core bits merge -- like the clock and
power domain updates ISTR you wanted to hold back -- then the rest
starts to make sense upstream.  Things like board support, and the
drivers needed by those boards.


> There are two approaches to achieve that: take each driver, polish it
> for weeks on end until it's nice and shiney, and then submit it upstream.
> ...
> The other approach is to decide that we have what we have, and that in
> the interests of efficiently reducing divergence, merging the upstream
> changes with the downstream changes and pushing the result upstream ASAP.

Those are two ends of a *spectrum* reflecting how much work to put in,
not two different "approaches".  Between those ends are MANY other
options.  Those two ends are rarely used.

Those options include what I've always thought is the norm:  review
drivers as part of upstream submission, and resolve most issues before
they get merged.  (It's an acknowledged issue that resolving them later
tends to be quite difficult...)


There's also the issue of strategy.  One can randomly take changes
and merge them ... possibly leaving upstream a bit chaotic.  One
could try to merge everything at once ... unrealistic.  One could
merge enough to meet specific functional targets ... which makes
more sense to me.  (Example:  "2.6.28 should boot beagleboard.org
and gumstix Overo from mainline."  That might even be achievable...)


> > If you *really* wanted to avoid wasting time you wouldn't have
> > replied to my previous post, which agreed that one point I raised
> > was a non-issue for this particular patch series.
> 
> Wim said: "Will add patches 1 to 3 when everyone is OK with them. I
> still saw some comments from David."

Yes, there are two unresolved issues in patch #1 which you seem
to have successfully buried with your flamage.  Easy fixes, just
strike a line and truncate a path.  The sort of thing that often
gets queued in the MM tree as a "fixup" and then merged into a
main patch.

- Dave
--
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/

Powered by blists - more mailing lists