Re: [PLUG] "Endian" Programming Question

The order of the bytes may be swapped according to the endian-ness.
The order of the bits within a byte never changes.
So, since this is an 8-byte number, you'd either have bits like this:
1 - 8, 8 - 16, ... , 50 - 58, 57 - 64
or you'd have

57 - 64, 50 - 58, ... , 8 - 16, 1 - 8
or in bytes, either
1, 2, ... , 7, 8
or
8, 7, ... , 2, 1

If you were reading/writing a 2 byte int followed by a 4 byte int, it'd probably be something like:
1, 2, 1, 2, 3, 4
or
2, 1, 4, 3, 2, 1

http://en.wikipedia.org/wiki/Endian

From: Casey Bralla <MailList@NerdWorld.org>
To: Philadelphia Linux User's Group Discussion List <plug@lists.phillylinux.org>
Sent: Sunday, March 1, 2009 3:03:13 PM
Subject: [PLUG] "Endian" Programming Question

I'm confused by the notion of "Big Endian" and "Little Endian" formats
(actually, I'm confused by a lot of things, but this is the most recent
manifestation <grin>) I was hoping someone on this list could help me better
understand this.

I'm working on a Python application that will read info from some /proc files
and display where individual files are in physical memory. The
file /proc/pid/pagemap is a wealth of info, coded as a 64-bit number. From
the kernel text file:

* /proc/pid/pagemap. This file lets a userspace process find out which
physical frame each virtual page is mapped to. It contains one 64-bit
value for each virtual page, containing the following data (from
fs/proc/task_mmu.c, above pagemap_read):

* Bits 0-55 page frame number (PFN) if present
* Bits 0-4 swap type if swapped
* Bits 5-55 swap offset if swapped
* Bits 55-60 page shift (page size = 1<<page shift)
* Bit 61 reserved for future use
* Bit 62 page swapped
* Bit 63 page present

If the page is not present but in swap, then the PFN contains an
encoding of the swap file number and the page's offset into the
swap. Unmapped pages return a null PFN. This allows determining
precisely which pages are mapped (or in swap) and comparing mapped
pages between processes.

Since the pagemap data is a series of 64-bit long numbers, I thought I would
read it into a python string variable that is 8 characters long. Then I
could parse out the individual bits to get the Page Frame Numbers (PFN).

But here is where I'm confused: Is the "first" 8-bit character the "high"
bits for the PFN, or the "low" bits. Is the high bit within the character
the high bit for the PFN?

I eMailed the author of this kernel module, and he told me that the "endian"
nature of the data follows the format for the cpu, which is "Little Endian"
for x86's. OK, that's like saying it's written in Latin instead of Greek.
<sigh>

Can anybody help me figure this thing out?

--

Casey Bralla
Chief Nerd in Residence
The NerdWorld Organisation
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug