linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Date: Wed, 02 Mar 2011 14:51:12 +1300	[thread overview]
Message-ID: <4D6DA290.2010607@bluewatersys.com> (raw)
In-Reply-To: <4D6D9FC7.1090206@codeaurora.org>

On 03/02/2011 02:39 PM, Saravana Kannan wrote:
> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>> <skannan@codeaurora.org>   wrote:
>>
>> <snip>
>>
>>>> What would an "arch" file mean? The name of the soc platform?
>>>
>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>> similar paths. If that info is already available elsewhere, then that
>>> file is not needed. I proposed using the arch since that will remove the
>>> need to maintain some database of unique/reserved names/numbers for each
>>> implementation of socinfo (like the machinetypes list we have).
>>
>> /proc/cpuinfo already tells you what the CPU is, which gives more
>> information than just the architecture name.
>>
>> Why is the arch information even required by userspace?
> 
> The socinfo exported by each soc is different. If userspace is trying to
> make decisions based on socinfo, it will need to know what type of soc
> (really what type of socinfo implementation) it is before trying to
> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
> different from socinfo -- the cpu is just a small part of a soc.

I understand that having a socinfo file for obtaining information about
a particular SoC would be useful. A similar discussion came up a few
years ago when we talked about having a socinfo file for exposing the
ep93xx Maverick crunch id, but nothing ever came out of it.

What I don't understand is why you want the 'arch' file (ie the
mach-xxxx) name. /proc/cpuinfo already gives you more information than
an 'arch' file would. I also can't think of a particularly good
situation why userspace would need to know at runtime what the
architecture is.

Have a socinfo file to expose implementation details of the particular
SoC I am fine with (assuming those details are useful to userspace),
having an 'arch' file to expose the architecture I am against.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

  reply	other threads:[~2011-03-02  1:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 14:15 [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 1/3] procfs: Introduce socinfo under /proc Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo Eduardo Valentin
2010-05-11 14:28   ` Nishanth Menon
2010-05-11 16:58     ` Eduardo Valentin
2010-05-12 12:34       ` Eduardo Valentin
2010-05-12 12:36         ` Nishanth Menon
2010-05-11 14:15 ` [PATCHv5 3/3] OMAP3: export chip IDCODE, Production ID and Die ID Eduardo Valentin
2010-05-12 22:24 ` [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data Andrew Morton
2010-05-14  8:24   ` Eduardo Valentin
2010-05-14 16:27   ` Tony Lindgren
2011-02-15 12:58 ` Linus Walleij
2011-02-16 11:57   ` Eduardo Valentin
2011-02-28 10:28     ` Maxime Coquelin
2011-03-01  4:51       ` Saravana Kannan
2011-03-02  1:13         ` Andrei Warkentin
2011-03-02  1:19           ` Saravana Kannan
2011-03-02  1:27             ` Ryan Mallon
2011-03-02  1:39               ` Saravana Kannan
2011-03-02  1:51                 ` Ryan Mallon [this message]
2011-03-02  2:23                   ` Saravana Kannan
2011-03-02  2:41                     ` Ryan Mallon
2011-03-02  2:55                       ` Saravana Kannan
2011-03-02  3:11                         ` Ryan Mallon
2011-03-02  3:21                           ` Saravana Kannan
2011-03-02  3:35                             ` Ryan Mallon
2011-03-02  3:46                               ` Saravana Kannan
2011-03-02  3:54                                 ` Ryan Mallon
2011-03-02  8:50                                   ` Maxime Coquelin
2011-03-02 20:09                                     ` Ryan Mallon
2011-03-02  8:23                         ` Maxime Coquelin
2011-03-02 10:36                           ` Linus Walleij
2011-03-02 10:53                             ` Maxime Coquelin
2011-03-03  5:55                               ` Saravana Kannan
2011-03-02 11:38                             ` Jamie Iles
2011-03-02 12:17                               ` Maxime Coquelin
2011-03-02 14:42                               ` Linus Walleij
2011-03-02 15:18                                 ` Jamie Iles

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D6DA290.2010607@bluewatersys.com \
    --to=ryan@bluewatersys.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).