From: David Daney <ddaney.cavm@gmail.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>,
Joshua Kinard <kumba@gentoo.org>,
Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo
Date: Wed, 21 Jan 2015 10:18:08 -0800 [thread overview]
Message-ID: <54BFED60.6040505@gmail.com> (raw)
In-Reply-To: <20150121134927.GJ1205@linux-mips.org>
On 01/21/2015 05:49 AM, Ralf Baechle wrote:
> On Wed, Jan 21, 2015 at 10:22:30AM +0000, Markos Chandras wrote:
>
>>>>> What would use this? Or in other words, why is this needed?
>>>>
>>>> It was a patch I started including years ago in Gentoo's mips-sources, and just
>>>> never thought much about. I know it was submitted several times in the past,
>>>> but I can't recall what, if any objection was ever made. No harm in sending it
>>>> in again...
>>>
>>> Clarification, submitted several times in the past by others. I think I sent
>>> it in once prior, but never got review or feedback.
>>>
>> I believe this patch is mostly useful for cores that can boot in both LE
>> and BE so being able to tell the byteorder from cpuinfo can be helpful
>> at times. Having readelf and other tools in your userland may not always
>> be the case, but you surely have "cat" :)
>>
>> So that patch looks good to me but i think the #ifdefs can be avoided.
>> Can we use
>>
>> if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {
>> } else {
>> }
>>
>> stuff instead?
>
> Exactly the code Joshua is submitting is what has been there until commit
> 874124ebb630 (Merge with Linux 2.4.15.) in 2001. One reason to remove it
> was that I had a prototype of a kernel supporting the execution of
> application of native and the other byte order working and the field in
> /proc/cpuinfo was plain lying in that case. Not a terribly relevant
> reason in retrospective but I'm wondering if just in case we should
> rename the field to kernel_byteorder?
>
This is kind of my reason for questioning adding this thing in the first
place.
Any user of the data probably wouldn't be ready for the case you
mention. *And* the data is available from other sources.
> Ralf
>
next prev parent reply other threads:[~2015-01-21 18:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 9:02 [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo Joshua Kinard
2015-01-20 23:05 ` David Daney
2015-01-21 2:45 ` Joshua Kinard
2015-01-21 2:54 ` Joshua Kinard
2015-01-21 10:22 ` Markos Chandras
2015-01-21 11:26 ` Joshua Kinard
2015-01-21 13:49 ` Ralf Baechle
2015-01-21 18:18 ` David Daney [this message]
2015-01-21 18:38 ` Aaro Koskinen
2015-01-21 18:42 ` David Daney
2015-01-26 8:06 ` Maciej W. Rozycki
2015-01-26 13:16 ` Ralf Baechle
2015-01-26 14:53 ` Maciej W. Rozycki
2015-01-26 18:15 ` David Daney
2015-01-26 19:39 ` Maciej W. Rozycki
2015-01-26 20:13 ` David Daney
2015-01-27 16:15 ` Maciej W. Rozycki
2015-01-27 19:57 ` David Daney
2015-02-05 13:46 ` Maciej W. Rozycki
2015-02-05 15:28 ` Måns Rullgård
2015-02-05 16:12 ` Maciej W. Rozycki
2015-02-05 19:36 ` Måns Rullgård
2015-02-05 16:27 ` David Daney
2015-02-05 21:02 ` Maciej W. Rozycki
2015-01-21 6:50 ` Antony Pavlov
2015-02-12 4:16 ` Joshua Kinard
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=54BFED60.6040505@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=Markos.Chandras@imgtec.com \
--cc=kumba@gentoo.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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 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.