From: Ryan Mallon <ryan@bluewatersys.com>
To: Saravana Kannan <skannan@codeaurora.org>
Cc: ext Nishanth Menon <nm@ti.com>,
ext Tony Lindgren <tony@atomide.com>,
Peter De-Schrijver <Peter.De-Schrijver@nokia.com>,
ext Linus Walleij <linus.walleij@linaro.org>,
Ambresh <a0393775@ti.com>,
Andrei Warkentin <andreiw@motorola.com>,
Lee Jones <Lee.Jones@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Jonas ABERG <jonas.aberg@stericsson.com>,
ext Kevin Hilman <khilman@deeprootsystems.com>,
David Brown <davidb@codeaurora.org>,
Maxime Coquelin <maxime.coquelin-nonst@stericsson.com>,
linux-arm-msm@vger.kernel.org, loic.pallardy@stericsson.com,
"eduardo.valentin@nokia.com" <eduardo.valentin@nokia.com>,
Linux-OMAP <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Daniel Walker <dwalker@codeaurora.org>,
LKML <linux-kernel@vger.kernel.org>,
Jouni Hogander <jouni.hogander@nokia.com>,
Paul Mundt <lethal@linux>
Subject: Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Date: Wed, 02 Mar 2011 16:54:01 +1300 [thread overview]
Message-ID: <4D6DBF59.2050005@bluewatersys.com> (raw)
In-Reply-To: <4D6DBD8C.70904@codeaurora.org>
On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
<snip>
>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
>
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
>
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.
Agreed.
In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@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
WARNING: multiple messages have this Message-ID (diff)
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 16:54:01 +1300 [thread overview]
Message-ID: <4D6DBF59.2050005@bluewatersys.com> (raw)
In-Reply-To: <4D6DBD8C.70904@codeaurora.org>
On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
<snip>
>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
>
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
>
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.
Agreed.
In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".
~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
WARNING: multiple messages have this Message-ID (diff)
From: Ryan Mallon <ryan@bluewatersys.com>
To: Saravana Kannan <skannan@codeaurora.org>
Cc: ext Nishanth Menon <nm@ti.com>,
ext Tony Lindgren <tony@atomide.com>,
Peter De-Schrijver <Peter.De-Schrijver@nokia.com>,
ext Linus Walleij <linus.walleij@linaro.org>,
Ambresh <a0393775@ti.com>,
Andrei Warkentin <andreiw@motorola.com>,
Lee Jones <Lee.Jones@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Jonas ABERG <jonas.aberg@stericsson.com>,
ext Kevin Hilman <khilman@deeprootsystems.com>,
David Brown <davidb@codeaurora.org>,
Maxime Coquelin <maxime.coquelin-nonst@stericsson.com>,
linux-arm-msm@vger.kernel.org, loic.pallardy@stericsson.com,
"eduardo.valentin@nokia.com" <eduardo.valentin@nokia.com>,
Linux-OMAP <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Daniel Walker <dwalker@codeaurora.org>,
LKML <linux-kernel@vger.kernel.org>,
Jouni Hogander <jouni.hogander@nokia.com>,
Paul Mundt <lethal@linux-sh.org>,
"santosh.shilimkar@ti.com" <santosh.shilimkar@ti.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Date: Wed, 02 Mar 2011 16:54:01 +1300 [thread overview]
Message-ID: <4D6DBF59.2050005@bluewatersys.com> (raw)
In-Reply-To: <4D6DBD8C.70904@codeaurora.org>
On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
<snip>
>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
>
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
>
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.
Agreed.
In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@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
next prev parent reply other threads:[~2011-03-02 3:54 UTC|newest]
Thread overview: 89+ 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 ` Eduardo Valentin
2010-05-11 14:15 ` Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 1/3] procfs: Introduce socinfo under /proc Eduardo Valentin
2010-05-11 14:15 ` Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo Eduardo Valentin
2010-05-11 14:15 ` Eduardo Valentin
2010-05-11 14:28 ` Nishanth Menon
2010-05-11 14:28 ` Nishanth Menon
2010-05-11 16:58 ` Eduardo Valentin
2010-05-11 16:58 ` Eduardo Valentin
2010-05-12 12:34 ` Eduardo Valentin
2010-05-12 12:34 ` Eduardo Valentin
2010-05-12 12:36 ` Nishanth Menon
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-11 14:15 ` Eduardo Valentin
2010-05-11 14:15 ` 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-12 22:24 ` Andrew Morton
2010-05-14 8:24 ` Eduardo Valentin
2010-05-14 8:24 ` Eduardo Valentin
2010-05-14 8:24 ` Eduardo Valentin
2010-05-14 16:27 ` Tony Lindgren
2010-05-14 16:27 ` Tony Lindgren
2011-02-15 12:58 ` Linus Walleij
2011-02-15 12:58 ` Linus Walleij
2011-02-16 11:57 ` Eduardo Valentin
2011-02-16 11:57 ` Eduardo Valentin
2011-02-28 10:28 ` Maxime Coquelin
2011-02-28 10:28 ` Maxime Coquelin
2011-02-28 10:28 ` Maxime Coquelin
2011-03-01 4:51 ` Saravana Kannan
2011-03-01 4:51 ` Saravana Kannan
2011-03-01 4:51 ` Saravana Kannan
2011-03-02 1:13 ` Andrei Warkentin
2011-03-02 1:13 ` Andrei Warkentin
2011-03-02 1:13 ` Andrei Warkentin
2011-03-02 1:19 ` Saravana Kannan
2011-03-02 1:19 ` Saravana Kannan
2011-03-02 1:19 ` Saravana Kannan
2011-03-02 1:27 ` Ryan Mallon
2011-03-02 1:27 ` Ryan Mallon
2011-03-02 1:39 ` Saravana Kannan
2011-03-02 1:39 ` Saravana Kannan
2011-03-02 1:51 ` Ryan Mallon
2011-03-02 1:51 ` Ryan Mallon
2011-03-02 2:23 ` Saravana Kannan
2011-03-02 2:23 ` Saravana Kannan
2011-03-02 2:41 ` Ryan Mallon
2011-03-02 2:41 ` Ryan Mallon
2011-03-02 2:55 ` Saravana Kannan
2011-03-02 2:55 ` Saravana Kannan
2011-03-02 2:55 ` Saravana Kannan
2011-03-02 3:11 ` Ryan Mallon
2011-03-02 3:11 ` Ryan Mallon
2011-03-02 3:11 ` Ryan Mallon
2011-03-02 3:21 ` Saravana Kannan
2011-03-02 3:21 ` Saravana Kannan
2011-03-02 3:21 ` Saravana Kannan
2011-03-02 3:35 ` Ryan Mallon
2011-03-02 3:35 ` Ryan Mallon
2011-03-02 3:35 ` Ryan Mallon
2011-03-02 3:46 ` Saravana Kannan
2011-03-02 3:46 ` Saravana Kannan
2011-03-02 3:46 ` Saravana Kannan
2011-03-02 3:54 ` Ryan Mallon [this message]
2011-03-02 3:54 ` Ryan Mallon
2011-03-02 3:54 ` Ryan Mallon
2011-03-02 8:50 ` Maxime Coquelin
2011-03-02 8:50 ` Maxime Coquelin
2011-03-02 20:09 ` Ryan Mallon
2011-03-02 20:09 ` Ryan Mallon
2011-03-02 8:23 ` Maxime Coquelin
2011-03-02 8:23 ` Maxime Coquelin
2011-03-02 10:36 ` Linus Walleij
2011-03-02 10:36 ` Linus Walleij
2011-03-02 10:53 ` Maxime Coquelin
2011-03-02 10:53 ` Maxime Coquelin
2011-03-03 5:55 ` Saravana Kannan
2011-03-03 5:55 ` Saravana Kannan
2011-03-02 11:38 ` Jamie Iles
2011-03-02 11:38 ` Jamie Iles
2011-03-02 12:17 ` Maxime Coquelin
2011-03-02 12:17 ` Maxime Coquelin
2011-03-02 14:42 ` Linus Walleij
2011-03-02 14:42 ` Linus Walleij
2011-03-02 15:18 ` Jamie Iles
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=4D6DBF59.2050005@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=Lee.Jones@linaro.org \
--cc=Peter.De-Schrijver@nokia.com \
--cc=a0393775@ti.com \
--cc=andreiw@motorola.com \
--cc=davidb@codeaurora.org \
--cc=dwalker@codeaurora.org \
--cc=eduardo.valentin@nokia.com \
--cc=jonas.aberg@stericsson.com \
--cc=jouni.hogander@nokia.com \
--cc=khilman@deeprootsystems.com \
--cc=lethal@linux \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=loic.pallardy@stericsson.com \
--cc=maxime.coquelin-nonst@stericsson.com \
--cc=nm@ti.com \
--cc=skannan@codeaurora.org \
--cc=tony@atomide.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.