content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [PATCH] Make modules work in Linus' tree on ARM
Date: Thu, 14 Aug 2003 10:42:52 -0700
Message-ID: <DD755978BA8283409FB0087C39132BD101B01074@fmsmsx404.fm.intel.com>
Thread-Topic: Re: [PATCH] Make modules work in Linus' tree on ARM
Thread-Index: AcNii3zB73/EApMeQKW+0by+kdjj+A==
From: "Luck, Tony" <tony.luck@intel.com>
To: <torvalds@osdl.org>
Cc: <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1356
Lines: 34

Linus Torvalds wrote:
> On Thu, 14 Aug 2003, Russell King wrote:
> 
>>After reviewing the /proc/kcore and kclist issues, I've decided that I'm
>>no longer prepared to even _think_ about supporting /proc/kcore on ARM -
> 
> 
> I suspect we should just remove it altogether.
> 
> Does anybody actually _use_ /proc/kcore? It was one of those "cool 
> feature" things, but I certainly haven't ever used it myself except for 
> testing, and it's historically often been broken after various kernel 
> infrastructure updates, and people haven't complained..

I only fixed it up because someone at SGI complained that
my ia64 kernel virtual space re-arrangements had broken it
(even more ... it had never been right for ia64).

Even now, it's still full of races (e.g. if you start gdb to
look at /proc/kcore, then load or unload modules).

Plus gdb doesn't really understand that kcore is a special
file, so it caches values (read "jiffies" twice and notice
that it doesn't change ... because gdb cached the read).

So don't mistake my recent activity fixing kcore for interest
in its continued existence.

-Tony Luck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/