Octal vs. Hex war o' death

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

diff -urP virgin-linux/drivers/block/rd.c linux/drivers/block/rd.c
@@ -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);

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Followup to:  <[email protected]>
By author:    Jeff Epler <[email protected]>
In newsgroup: linux.dev.kernel

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

<[email protected]> at work, <[email protected]> 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/