Why is byteorder removed from /proc/cpuinfo?

Why is byteorder removed from /proc/cpuinfo?

[H . J . Lu]

The byteorder field is emoved from /proc/cpuinfo in the current 2.4
kernel in CVS. It breaks config.guess used by all the GNU softwares.


H.J.

Re: Why is byteorder removed from /proc/cpuinfo?

[H . J . Lu]

On Thu, Dec 06, 2001 at 09:35:06AM -0800, H . J . Lu wrote:
> The byteorder field is emoved from /proc/cpuinfo in the current 2.4
> kernel in CVS. It breaks config.guess used by all the GNU softwares.
> 
> 

Here is a patch.

H.J.
----
--- arch/mips/kernel/proc.c.endian	Wed Dec  5 08:02:53 2001
+++ arch/mips/kernel/proc.c	Thu Dec  6 09:41:35 2001
@@ -42,6 +42,12 @@ static int show_cpuinfo(struct seq_file 
 	                            mips_cpu.cputype : CPU_UNKNOWN],
 	                           (version >> 4) & 0x0f, version & 0x0f,
 	                           (fp_vers >> 4) & 0x0f, fp_vers & 0x0f);
+#if __BIG_ENDIAN
+	seq_printf(m, "byteorder\t\t: big endian\n");
+#endif
+#if __LITTLE_ENDIAN
+	seq_printf(m, "byteorder\t\t: little endian\n");
+#endif
 	seq_printf(m, "BogoMIPS\t\t: %lu.%02lu\n",
 	              (loops_per_jiffy + 2500) / (500000/HZ),
 	              ((loops_per_jiffy + 2500) / (5000/HZ)) % 100);

Re: Why is byteorder removed from /proc/cpuinfo?

[Ralf Baechle]

On Thu, Dec 06, 2001 at 09:35:06AM -0800, H . J . Lu wrote:

> The byteorder field is emoved from /proc/cpuinfo in the current 2.4
> kernel in CVS. It breaks config.guess used by all the GNU softwares.

Grrr...  In the past config.guess used gcc to compile a test program using
gcc.  I told sometime ago to whoever it was that I'm going to remove
all non-cpu related information (endianess should be considered per
_thread_ on MIPS!) from /proc/cpuinfo where it has no business; the /proc
rewrite in 2.4.15 more or less forced me into this.

  Ralf

PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[H . J . Lu]

On Thu, Dec 06, 2001 at 03:57:24PM -0200, Ralf Baechle wrote:
> On Thu, Dec 06, 2001 at 09:35:06AM -0800, H . J . Lu wrote:
> 
> > The byteorder field is emoved from /proc/cpuinfo in the current 2.4
> > kernel in CVS. It breaks config.guess used by all the GNU softwares.
> 
> Grrr...  In the past config.guess used gcc to compile a test program using
> gcc.  I told sometime ago to whoever it was that I'm going to remove
> all non-cpu related information (endianess should be considered per
> _thread_ on MIPS!) from /proc/cpuinfo where it has no business; the /proc
> rewrite in 2.4.15 more or less forced me into this.
> 

How about this patch?


H.J.
---
2001-12-06  H.J. Lu  (hjl@gnu.org)

	* config.guess: Properly handle Linux/mips.

--- config.guess.mips	Mon Nov  5 08:09:32 2001
+++ config.guess	Thu Dec  6 10:31:40 2001
@@ -767,10 +767,21 @@ EOF
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit 0 ;;
     mips:Linux:*:*)
-	case `sed -n '/^byte/s/^.*: \(.*\) endian/\1/p' < /proc/cpuinfo` in
-	  big)    echo mips-unknown-linux-gnu && exit 0 ;;
-	  little) echo mipsel-unknown-linux-gnu && exit 0 ;;
-	esac
+	eval $set_cc_for_build
+	cat >$dummy.c <<EOF
+#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
+cpu=mipsel
+#endif
+#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
+cpu=mips
+#endif
+EOF
+	cpu=
+	eval `$CC_FOR_BUILD -E $dummy.c | grep cpu=`;
+	rm -f $dummy.c
+	if test -n "$cpu"; then
+	  echo $cpu-unknown-linux-gnu && exit 0
+	fi
 	;;
     ppc:Linux:*:*)
 	echo powerpc-unknown-linux-gnu

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ralf Baechle]

On Thu, Dec 06, 2001 at 10:36:05AM -0800, H . J . Lu wrote:

> How about this patch?

Looks good to me except that checking for __MIPSE[LB]__ should be
sufficient.  Anything that doesn't provide these two symbols wouldn't
have the chance of a snowball in hell to work.

  Ralf

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[H . J . Lu]

On Thu, Dec 06, 2001 at 04:41:53PM -0200, Ralf Baechle wrote:
> On Thu, Dec 06, 2001 at 10:36:05AM -0800, H . J . Lu wrote:
> 
> > How about this patch?
> 
> Looks good to me except that checking for __MIPSE[LB]__ should be
> sufficient.  Anything that doesn't provide these two symbols wouldn't
> have the chance of a snowball in hell to work.
> 

I added those just in case someone wants to use a different compiler
to bootstrap gcc on Linux/mips :-). I don't think it will hurt anyhing.


H.J.

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ralf Baechle]

On Thu, Dec 06, 2001 at 10:51:42AM -0800, H . J . Lu wrote:

> > > How about this patch?
> > 
> > Looks good to me except that checking for __MIPSE[LB]__ should be
> > sufficient.  Anything that doesn't provide these two symbols wouldn't
> > have the chance of a snowball in hell to work.
> > 
> 
> I added those just in case someone wants to use a different compiler
> to bootstrap gcc on Linux/mips :-). I don't think it will hurt anyhing.

Sure, it won't.  And those guys who don't use a Linux/MIPS compiler seem
to be decieded to have _alot_ of extra fun anyway :-)

  Ralf

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

  >> Grrr...  In the past config.guess used gcc to compile a test program using
  >> gcc.  I told sometime ago to whoever it was that I'm going to remove
  >> all non-cpu related information (endianess should be considered per
  >> _thread_ on MIPS!) from /proc/cpuinfo where it has no business; the /proc
  >> rewrite in 2.4.15 more or less forced me into this.

  H> How about this patch?

Please, no.  I have worked very hard to eliminate many of the
instances where it has been necessary to compile dummy programs in
config.guess.  They are troublesome to many config.guess users.  How
about this instead?


  cpu=`cpp << EOF | grep ^mips
#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
mipsel
#endif
#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
mips
#endif
EOF`
  if test -n "$cpu" ; then
    echo $cpu-unknown-linux-gnu && exit 0
  fi


Please try this out on a MIPS Linux system and, if it works, resubmit
a new patch along these lines.  Thanks,

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

>>>>> "Ben" == Ben Elliston <bje@redhat.com> writes:

  Ben>   cpu=`cpp << EOF | grep ^mips

Of course, this needs some refinement.  ;-) Perhaps we need to run
through $(CC_FOR_BUILD) -E or somesuch; cpp is no good, as it won't
know all of the magic '*MIPS*' #defines.

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Daniel Jacobowitz]

On Mon, Dec 10, 2001 at 08:42:31PM +1100, Ben Elliston wrote:
> >>>>> "Ben" == Ben Elliston <bje@redhat.com> writes:
> 
>   Ben>   cpu=`cpp << EOF | grep ^mips
> 
> Of course, this needs some refinement.  ;-) Perhaps we need to run
> through $(CC_FOR_BUILD) -E or somesuch; cpp is no good, as it won't
> know all of the magic '*MIPS*' #defines.

HJ's patch didn't compile anything; it ran code through
$(CC_FOR_BUILD) -E :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

> > Of course, this needs some refinement.  ;-) Perhaps we need to run
> > through $(CC_FOR_BUILD) -E or somesuch; cpp is no good, as it won't
> > know all of the magic '*MIPS*' #defines.

> HJ's patch didn't compile anything; it ran code through
> $(CC_FOR_BUILD) -E :)

I must admit, I missed that.  But I definitely noticed that it created 
temporary files, which are more trouble than they're worth.  The number of 
people running ./configure as root is frightening.

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

> > Of course, this needs some refinement.  ;-) Perhaps we need to run
> > through $(CC_FOR_BUILD) -E or somesuch; cpp is no good, as it won't
> > know all of the magic '*MIPS*' #defines.

> HJ's patch didn't compile anything; it ran code through
> $(CC_FOR_BUILD) -E :)

I must admit, I missed that.  But I definitely noticed that it created 
temporary files, which are more trouble than they're worth.  The number of 
people running ./configure as root is frightening.

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[H . J . Lu]

On Tue, Dec 11, 2001 at 09:34:52AM +1000, Ben Elliston wrote:
> > > Of course, this needs some refinement.  ;-) Perhaps we need to run
> > > through $(CC_FOR_BUILD) -E or somesuch; cpp is no good, as it won't
> > > know all of the magic '*MIPS*' #defines.
> 
> > HJ's patch didn't compile anything; it ran code through
> > $(CC_FOR_BUILD) -E :)
> 
> I must admit, I missed that.  But I definitely noticed that it created 
> temporary files, which are more trouble than they're worth.  The number of 
> people running ./configure as root is frightening.

I don't want to assume $(CC_FOR_BUILD) can take - as input.


H.J.

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

  H> I don't want to assume $(CC_FOR_BUILD) can take - as input.

But you can assume that you're running on a MIPS Linux system.

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[H . J . Lu]

On Tue, Dec 11, 2001 at 11:23:06AM +1100, Ben Elliston wrote:
> >>>>> "H" == H J Lu <hjl@lucon.org> writes:
> 
>   H> I don't want to assume $(CC_FOR_BUILD) can take - as input.
> 
> But you can assume that you're running on a MIPS Linux system.
> 

Why can't Linux/mips have another compiler?


H.J.

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ralf Baechle]

On Mon, Dec 10, 2001 at 08:42:31PM +1100, Ben Elliston wrote:

>   Ben>   cpu=`cpp << EOF | grep ^mips
> 
> Of course, this needs some refinement.  ;-) Perhaps we need to run
> through $(CC_FOR_BUILD) -E or somesuch; cpp is no good, as it won't
> know all of the magic '*MIPS*' #defines.

Agreed but the basic idea is good.  Also this solution is suitable for
crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
properly installed libraries and headers might possibly of interest for
building standalone software.

  Ralf

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Maciej W. Rozycki]

On Mon, 10 Dec 2001, Ralf Baechle wrote:

> Agreed but the basic idea is good.  Also this solution is suitable for
> crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
> properly installed libraries and headers might possibly of interest for
> building standalone software.

 Hmm, I don't think config.guess is ever used for cross-compilation as the
script's purpose is to guess the host and you need to specify one
explicitly for a cross-compilation to happen.  Anyway it's saner not to
use build system properties to guess host system ones.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

> > crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
> > properly installed libraries and headers might possibly of interest for
> > building standalone software.

>  Hmm, I don't think config.guess is ever used for cross-compilation as
> the script's purpose is to guess the host and you need to specify one
> explicitly for a cross-compilation to happen.  Anyway it's saner not
> to use build system properties to guess host system ones.

You're close, but not quite correct.  In a cross-compilation environment,
the job of config.guess is to determine the type of the build system,
which may be different to the host and will certainly be different to the
target.

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

> > crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
> > properly installed libraries and headers might possibly of interest for
> > building standalone software.

>  Hmm, I don't think config.guess is ever used for cross-compilation as
> the script's purpose is to guess the host and you need to specify one
> explicitly for a cross-compilation to happen.  Anyway it's saner not
> to use build system properties to guess host system ones.

You're close, but not quite correct.  In a cross-compilation environment,
the job of config.guess is to determine the type of the build system,
which may be different to the host and will certainly be different to the
target.

Ben

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Maciej W. Rozycki]

On Tue, 11 Dec 2001, Ben Elliston wrote:

> >  Hmm, I don't think config.guess is ever used for cross-compilation as
> > the script's purpose is to guess the host and you need to specify one
> > explicitly for a cross-compilation to happen.  Anyway it's saner not
> > to use build system properties to guess host system ones.
> 
> You're close, but not quite correct.  In a cross-compilation environment,
> the job of config.guess is to determine the type of the build system,

 It actually depends on the autoconf version -- historically it was
backwards.  Still, even if config.guess is used to determine the build
system, the script need not care about the host, so there's no problem
with the cross-compilation (apart from purity).

> which may be different to the host and will certainly be different to the
> target.

 Not necessarily, although unlikely, indeed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ralf Baechle]

On Tue, Dec 11, 2001 at 09:40:50AM +1000, Ben Elliston wrote:

> > > crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
> > > properly installed libraries and headers might possibly of interest for
> > > building standalone software.
> 
> >  Hmm, I don't think config.guess is ever used for cross-compilation as
> > the script's purpose is to guess the host and you need to specify one
> > explicitly for a cross-compilation to happen.  Anyway it's saner not
> > to use build system properties to guess host system ones.
> 
> You're close, but not quite correct.  In a cross-compilation environment,
> the job of config.guess is to determine the type of the build system,
> which may be different to the host and will certainly be different to the
> target.

In case of Linux/MIPS it could guess wether it's a little endian or big
endian configuration and emit mips-unknown-gnu-linux or
mipsel-unknown-gnu-linux that is taking away the burden of the user knowing
about the right endianess for his target - specifying mips-linux as target
should then be sufficient.  Does that sound sane or would overriding the
users explicitly give targetname (or even hostname for a native build) be
considered a bad thing?

  Ralf

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Daniel Jacobowitz]

On Tue, Dec 11, 2001 at 11:30:08AM -0200, Ralf Baechle wrote:
> On Tue, Dec 11, 2001 at 09:40:50AM +1000, Ben Elliston wrote:
> 
> > > > crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
> > > > properly installed libraries and headers might possibly of interest for
> > > > building standalone software.
> > 
> > >  Hmm, I don't think config.guess is ever used for cross-compilation as
> > > the script's purpose is to guess the host and you need to specify one
> > > explicitly for a cross-compilation to happen.  Anyway it's saner not
> > > to use build system properties to guess host system ones.
> > 
> > You're close, but not quite correct.  In a cross-compilation environment,
> > the job of config.guess is to determine the type of the build system,
> > which may be different to the host and will certainly be different to the
> > target.
> 
> In case of Linux/MIPS it could guess wether it's a little endian or big
> endian configuration and emit mips-unknown-gnu-linux or
> mipsel-unknown-gnu-linux that is taking away the burden of the user knowing
> about the right endianess for his target - specifying mips-linux as target
> should then be sufficient.  Does that sound sane or would overriding the
> users explicitly give targetname (or even hostname for a native build) be
> considered a bad thing?

Since specifying "mips-linux" is understood to mean big-endian right
now, I'd say yes...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)

[Ben Elliston]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

  H> How about this patch?

Reluctantly accepted.  I will apply to the FSF master copy tomorrow.

Ben

Re: Why is byteorder removed from /proc/cpuinfo?

[Dominic Sweetman]

Ralf Baechle (ralf@oss.sgi.com) writes:

> (endianess should be considered per _thread_ on MIPS!)

I tried to ignore this, but I can't.  Ralf, what an elegant idea, but
it really doesn't make much sense.  

Ralf is influenced, I think, by the fact that MIPS CPUs have two
endianness switches: a "one-time" select which needs to match some of
the rest of the hardware in your system, and is picked at reset time,
and the very dodgy status register 'RE' bit.  RE ("reverse endianness
in user mode") bit was invented in a fit of madness for the MIPS
R4000.  It was intended to make it possible to run binaries from the
little-endian DECstation on a big-endian MIPS unix system.  As far as
I know, nobody ever did the software work to make such a thing happen,
so nobody really ever found out if it would have worked.

So yes, you could try to change the RE bit between threads... but
threads generally expect to be able to share code and data.  Now:

1. MIPS code is endianness-dependent (your big- and little-endian
   threads would require separate copies of any library function, for
   example);

2. MIPS data is endianness-dependent.  The endianness-switch uses
   cheap and simple hardware and produces particularly nasty effects.
   That's OK when you are just doing a one-time select (effectively,
   the memory system inherits the CPU's endianness, hiding the
   nastiness).

   But a big-endian and little-endian thread sharing data will see
   everything mangled; in fact they'll only show mutual comprehension
   of data consisting of aligned words (either 32-bit or 64-bit,
   according to the underlying CPU).  A feature which allows you to
   tell whether you've got a 64-bit CPU while running 32-bit code is
   not good.

3. The one-time endianness switch also controls some peripheral (chip
   interface) logic.  The memory controller has to know the CPU's
   endianness to decode bus cycles, so the RE bit presumably must
   leave this alone: though on the original R4000 it happened that it
   didn't matter so long as the backward code stayed in cache...  be
   that as it may, it means this whole thing is even more broken for
   64-bit CPUs on a 32-bit bus, for example.

So:

a) Any MIPS system really does have an endianness: the kernel always
   runs in it.  Since the kernel binary is already committed to either
   big- or little-endian, it really is fairly appropriate to have a
   compile-time flag to say which.

b) Dynamic endianness is just plausible on a unix process basis
   (thread + address space), as originally planned: but the amount of
   kernel re-writing involved, plus a complete second set of dynamic
   libraries, plus endless problem in I/O make it easy to see why it
   never got done.

   Dynamic endianness on a per-thread basis would require fantasy
   hardware which operates differently from the way MIPS chips do...

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032
http://www.algor.co.uk

Re: Why is byteorder removed from /proc/cpuinfo?

[Ralf Baechle]

On Mon, Dec 10, 2001 at 06:40:00PM +0000, Dominic Sweetman wrote:

>    Dynamic endianness on a per-thread basis would require fantasy
>    hardware which operates differently from the way MIPS chips do...

I used the term thread as the c0_status register which contains the RE
bit is per process.  Keeping it a per mm thing would require more effort
for no good reason.  Anyway, inside the Linux kernel threads and processes
are basically the same thing.

  Ralf