[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [fwd] Re: + git-audit-master-build-fix.patch added to -mm tree

On Fri, Mar 03, 2006 at 10:25:48AM -0500, Alexander Viro wrote:
> On Fri, Mar 03, 2006 at 06:33:42AM -0500, Steve Grubb wrote:
> > I think Amy's patches fall into this same category, meaning they
> > need to be run in the lspp kernel first to make sure we agree that
> > they meet our needs before sending on to a larger community. 
> > 
> > The string interface patches have had enough run time in lspp
> > kernel that they can be moved to -mm tree. As a matter of fact,
> > some of Dustin's work depends on these patches and his is ready
> > to go into -mm tree, too (including the leak patch).
> > The only controversial work is the patches that touch inotify and
> > Jason's performance patch. I'd feel better if they get testing in
> > lspp kernel first.
> IMO Jason's stuff is OK.  inotify, OTOH, (a) conflicts with other
> stuff in -mm and (b) is not ready for any testing, period.  Version
> posted last week would deadlock instantly and that chunk is _the_
> reason for previous inotify-affecting patch.  Besides, Amy asked to
> move those to the end of queue, so that she could replace them with
> convenience.  Which is what had been done...
> I'm still not sure what to do with the string patch #2 - right now
> it's in amg.b2; if Amy is OK with moving it to main branch, I'll do
> that and Dustin's patches will follow immediately.

There shouldn't be any dependencies on the string #2 patch.  All of
the interface changes should be contained in the string #1 patch.  If
this is not the case, point me to the specific dependency and I'll fix

Separating the string #1 and string #2 patches did uncover a problem
I'd forgotten about.  The string #1 patch introduces a new function as
part of the interface changes.  Because it doesn't have a caller, it
generates build warnings, which akpm fixed in -mm by removing the

I'm not sure removing the function is the right thing to do; it seems
we might as well remove the whole patch in that case.

Would anyone have advice on how to properly introduce new interfaces
that may not yet have callers?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]