[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1bc66b163326564dafb5a7dd8959fd56.squirrel@webmail-b.css.fujitsu.com>
Date: Wed, 16 Sep 2009 20:17:52 +0900 (JST)
From: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>
To: Am?rico_Wang <xiyou.wangcong@...il.com>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kamezawa.hiroyu@...fujitsu.com
Subject: Re: kcore patches (was Re: 2.6.32 -mm merge plans)
Am.$(D+1rico_Wang さんは書きました:
> On Wed, Sep 16, 2009 at 7:15 AM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
>>#kcore-fix-proc-kcores-statst_size.patch: is it right?
>>kcore-fix-proc-kcores-statst_size.patch
>
> Hmm, I think KAMEZAWA Hiroyuki's patchset is a much better fix for this.
> Hiroyuki?
>
Hmm ? My set is not agaisnt "file size" of /proc/kcore.
One problem of this patch is..this makes size of /proc/kcore as 0 bytes.
Then, objdump cannot read this. (it checks file size.)
readelf can read this. (it ignores file size.)
I wonder what you mention is.... because we know precise kclist_xxx
after my series, we can calculate kcore's size in precise by
get_kcore_size().
It seems /proc's inode->i_size is "static" and we cannot
provides return value of get_kcore_size() directly. It may need
some work and should depends on my kclist_xxx patch sets which are not
in merge candidates. If you can wait, I'll do some work for fixing this
problem. (but will not be able to merge directly against upstream.)
But for now, we have to use some fixed value....and using above
patch for 2.6.31 is not very bad.
Thanks,
-Kame
--
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