Octal vs. Hex war o' death

Octal vs. Hex war o' death

[Ian S. Nelson]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

I'm sure this is a religious issue... but I'm going to suggest it
anyways because I spent a few minutes on it.

So I was hacking away trying to get my embedded box to run the correct
stuff after booting up and I ran into an octal speed bump.  You see, all
throughout rd.c there are these hex constants, like there should be.  In
fact most constants in the kernel are in the 2 friendliest number
formats known, hex and dec.

in rd.c there is an:
memset(buf, 0xe5, size);

a:
 printk("%c\b", rotator[rotate & 0x3]);

and a:
#define WSIZE 0x8000

and several others, all in hex.

Then I ran into this black sheep:
 if (buf[0] == 037 && ((buf[1] == 0213) || (buf[1] == 0236))) {


I vote that we make this consistent and fix it.  So I've included a
handy patch to correct this "bug."  My rationale is that a) most
constants are in hex or dec already,  b) my editor doesn't sport an
octal mode but it has a really handy hex mode that let's me do things
like load up an initrd and check to see that the first 2 bytes are set
correctly,  c) octals were invented for UNIX file permissions and not
programming, putting an extra "0" in there just doesn't make sense and
shouldn't change the meaning of the following digits, "0x" on the other
hand clearly denotes that you are not looking at a base 10 number.  In
math they teach you that you can arbitrarily add zeros to the front of a
number and not change it's meaning, such as the military frequently does
with time ("0700 hours.." which translates to "7:00" and not  "4:48")
and math goes together hand in hand with programming.  lastly, d) octal
numbers just don't have a good feeling to them, it's like your stuck at
half-duplex or something..



Ian


[-- Attachment #2: minutia.patch --]
[-- Type: text/plain, Size: 502 bytes --]

diff -urP virgin-linux/drivers/block/rd.c linux/drivers/block/rd.c
--- virgin-linux/drivers/block/rd.c	Fri Nov 17 17:46:55 2000
+++ linux/drivers/block/rd.c	Wed Nov 29 15:45:33 2000
@@ -497,7 +497,7 @@
 	/*
 	 * If it matches the gzip magic numbers, return -1
 	 */
-	if (buf[0] == 037 && ((buf[1] == 0213) || (buf[1] == 0236))) {
+	if (buf[0] == 0x1f && ((buf[1] == 0x8b) || (buf[1] == 0x9e))) {
 		printk(KERN_NOTICE
 		       "RAMDISK: Compressed image found at block %d\n",
 		       start_block);

Re: Octal vs. Hex war o' death

[Jeff Epler]

On Wed, Nov 29, 2000 at 04:27:04PM -0700, Ian S. Nelson wrote:
> c) octals were invented for UNIX file permissions and not
> programming

You must be joking.  Read much history of computing?  Or
alt.folklore.computers?  Octal was very natural for 18- and 36-bit
machines, after all.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Octal vs. Hex war o' death

[H. Peter Anvin]

Followup to:  <20001129181723.A2765@potty.housenet>
By author:    Jeff Epler <jepler@inetnebr.com>
In newsgroup: linux.dev.kernel
>
> On Wed, Nov 29, 2000 at 04:27:04PM -0700, Ian S. Nelson wrote:
> > c) octals were invented for UNIX file permissions and not
> > programming
> 
> You must be joking.  Read much history of computing?  Or
> alt.folklore.computers?  Octal was very natural for 18- and 36-bit
> machines, after all.
> 

Not to mention that it's still quite natural for a lot of machines.
If you ever look at raw x86 machine code, with it's 3-bit fields,
byteized octal actually makes it quite easy to read.

Octal probably predates hexadecimal, since it fit within the 0-9
digits most people used.  Hex is really the natural choice for
modern power-of-two-width machines, though.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

PROBLEM: do_try_free_pages failed for python

[Bob Tanner]

[1.] One line summary of the problem: PROBLEM: do_try_free_pages failed for
python 

[2.] Full description of the problem/report: Running 2.2.18pre22 on a dual
Sparc20 with 128Mb of RAM.

[3.] Keywords (i.e., modules, networking, kernel):
do_try_free_pages, Sparc

[4.] Kernel version (from /proc/version):
Linux version 2.2.18pre22 (natecars@warrior) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #2 SMP Mon Nov 20 14:16:58 CST 2000

[5.] Output of Oops.. message (if applicable) with symbolic information 
     resolved (see Documentation/oops-tracing.txt)
Not an Ooops.

[6.] A small shell script or example program which triggers the
     problem (if possible)
qrunner for the mailman-2.0 final package and more then 48 files in the qfiles
directory will trigger the problem.

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux warrior 2.2.18pre22 #2 SMP Mon Nov 20 14:16:58 CST 2000 sparc unknown
Kernel modules         2.3.20
Gnu C                  egcs-2.91.66
Binutils               2.9.5.0.22
Linux C Library        2.1.3
Dynamic linker         ldd (GNU libc) 2.1.3
Procps                 2.0.6
Mount                  2.10f
Net-tools              1.54
Console-tools          0.3.3
Sh-utils               2.0
Modules Loaded         

[7.2.] Processor information (from /proc/cpuinfo):
cpu		: ROSS HyperSparc RT625 or RT626
fpu		: ROSS HyperSparc combined IU/FPU
promlib		: Version 3 Revision 2
prom		: 2.25
type		: sun4m
ncpus probed	: 2
ncpus active	: 2
Cpu0Bogo	: 89.90
Cpu1Bogo	: 89.90
MMU type	: ROSS HyperSparc
invall		: 0
invmm		: 0
invrnge		: 0
invpg		: 0
contexts	: 4096
CPU0		: online
CPU1		: online
[7.3.] Module information (from /proc/modules):
Nothing

[7.4.] SCSI information (from /proc/scsi/scsi)
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SEAGATE  Model: ST15230N         Rev: 0298
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: EXABYTE  Model: EXB-8505         Rev: 0051
  Type:   Sequential-Access                ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: IBM      Model: DNES-318350      Rev: SA30
  Type:   Direct-Access                    ANSI SCSI revision: 03

[7.5.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):
$ cat swaps 
Filename			Type		Size	Used	Priority
/dev/sda4                       partition	131804	132	-1
/dev/sdb2                       partition	129596	0	-2

$ cat meminfo 
        total:    used:    free:  shared: buffers:  cached:
Mem:  130293760 127279104  3014656 29020160 81747968 24367104
Swap: 267673600   135168 267538432
MemTotal:    127240 kB
MemFree:       2944 kB
MemShared:    28340 kB
Buffers:      79832 kB
Cached:       23796 kB
SwapTotal:   261400 kB
SwapFree:    261268 kB

[X.] Other notes, patches, fixes, workarounds:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Octal vs. Hex war o' death

[Alexander Viro]

On Wed, 29 Nov 2000, Ian S. Nelson wrote:

> I'm sure this is a religious issue... but I'm going to suggest it
> anyways because I spent a few minutes on it.

[snip a boring troll]

Could you come up with something more, erm, amusing?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Octal vs. Hex war o' death

[Igmar Palsenberg]

> [snip a boring troll]

Please, don't insult my mother in law. She's not that boring ;P



	Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: do_try_free_pages failed for python

[Rik van Riel]

On Wed, 29 Nov 2000, Bob Tanner wrote:

> [1.] One line summary of the problem: PROBLEM: do_try_free_pages
> failed for python
> 
> [2.] Full description of the problem/report: Running 2.2.18pre22
> on a dual Sparc20 with 128Mb of RAM.

The important thing to know here is if you had swap
free when this error was occuring or not. If you
still had lots of swap free, this may mean that VM
in 2.2 still has some bugs left ...

regards,

Rik
--
Hollywood goes for world dumbination,
	Trailer at 11.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: do_try_free_pages failed for python

[Andrea Arcangeli]

On Thu, Nov 30, 2000 at 02:06:55PM -0200, Rik van Riel wrote:
> still had lots of swap free, this may mean that VM
> in 2.2 still has some bugs left ...

I guess it's the free_before_allocate band-aid that hurts in 2.2. That subtle
race condition is fixed efficiently in VM-global with per-process freelist
flushed atomically to the global freelist before allocation, so I'd suggest him
to try to reproduce on VM-global-7.

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre18/VM-global-2.2.18pre18-7.bz2

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/