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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
