[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100511031447.GB20453@linux-sh.org>
Date: Tue, 11 May 2010 12:14:47 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Eduardo Valentin <eduardo.valentin@...ia.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linux-OMAP <linux-omap@...r.kernel.org>,
Russell King <linux@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
ext Tony Lindgren <tony@...mide.com>,
ext Kevin Hilman <khilman@...prootsystems.com>,
"De-Schrijver Peter (Nokia-D/Helsinki)"
<Peter.De-Schrijver@...ia.com>,
"santosh.shilimkar@...com" <santosh.shilimkar@...com>,
Ambresh <a0393775@...com>,
"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [PATCHv4 1/4] procfs: Introduce socinfo under /proc
On Mon, May 10, 2010 at 03:55:49PM +0300, Eduardo Valentin wrote:
> On Mon, May 10, 2010 at 02:39:02PM +0200, ext Paul Mundt wrote:
> > Note that in the cpuinfo case there is often special handling for the
> > single (or boot CPU) case, such as printing out a descriptor for the
> > machine type and so on. You might be better off just extending cpuinfo
> > rather than introducing another /proc abstraction, presumably your
> > socinfo string will be fixed regardless of whether it's SMP or not.
>
> Yeah, I wouldn't expect it to change if it SMP or not. It should be fixed.
> Previous version of this change was actually extending ARM cpuinfo. The previous
> thread starts here:
> http://marc.info/?l=linux-omap&m=127304890312365&w=2
>
> But, the point of moving that to specific file was that soc info is not really cpu info.
>
It's up to you of course, but adding an extra file because of SoC/CPU
ambiguity seems pretty ugly. Almost all architectures already include
machine type descriptors in their cpuinfo output (as ARM does also) and
if you can justify that then certainly adding in some SoC-specific bits
isn't exactly much of a stretch.
These days you should have a pretty strong justification for adding new
procfs files, and this is certainly not one of them.
--
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