[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090509104409.GB16138@elte.hu>
Date: Sat, 9 May 2009 12:44:09 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: fengguang.wu@...el.com, fweisbec@...il.com, rostedt@...dmis.org,
a.p.zijlstra@...llo.nl, lizf@...fujitsu.com,
linux-kernel@...r.kernel.org, kosaki.motohiro@...fujitsu.com,
andi@...stfloor.org, mpm@...enic.com, adobriyan@...il.com,
linux-mm@...ck.org
Subject: Re: [PATCH 4/8] proc: export more page flags in /proc/kpageflags
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Fri, 8 May 2009 13:47:42 +0200
> Ingo Molnar <mingo@...e.hu> wrote:
>
> >
> > * Wu Fengguang <fengguang.wu@...el.com> wrote:
> >
> > > Export all page flags faithfully in /proc/kpageflags.
> >
> > Ongoing objection and NAK against extended haphazard exporting of
> > kernel internals via an ad-hoc ABI via ad-hoc, privatized
> > instrumentation that only helps the MM code and nothing else.
>
> You're a year too late. The pagemap interface is useful.
My NAK is against the extension of this mistake.
So is your answer to my NAK in essence:
" We merged crappy MM instrumentation a short year ago, too bad.
And because it was so crappy to be in /proc we are now also
treating it as a hard ABI, not as a debugfs interface - for that
single app that is using it. Furthermore, we are now going to
make the API and ABI even more crappy via patches queued up in
-mm, and we are ignoring NAKs. We are also going to make it even
harder to have sane, generic instrumentation in the upstream
kernel. Deal with it, this is our code and we can mess it up the
way we wish to, it's none of your business."
right?
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/
Powered by blists - more mailing lists