[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
it.

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
function.

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?

Thanks,
Amy


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