|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] "Endian" Programming Question
|
Based on naming origins, it seems that this is an issue that should not get
you down.
Big Endians and Little Endians come from "Gulliver's Travels" and the
completely meaningless reason that the Lilliputions had two factions who
hated each other's guts. Seems that the Dublin dean, Johnathan Swift, had an
opinion about both sides in the Prod vrs Papist that, unfortunately, has not
gone away.
In the original, the debate was based upon which side you open a hard boiled
egg from. Each were willing to ruin their civilization rather than concede.
bs
Quoting Casey Bralla <MailList@NerdWorld.org>:
> 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
>
___________________________________________________________________________
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
|
|