Josh Goldstein on 1 Mar 2009 14:14:56 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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
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
2, 1, 4, 3, 2, 1

From: Casey Bralla <>
To: Philadelphia Linux User's Group Discussion List <>
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. 

Can anybody help me figure this thing out?


Casey Bralla
Chief Nerd in Residence
The NerdWorld Organisation
Philadelphia Linux Users Group        --
Announcements -
General Discussion  --

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --