Thanks Bart; Irony. I wanted the program below to look while reading, re-reading the LWN.net article. On Wed, 2007-10-03 at 11:08 -0400, Bart Trojanowski wrote: > * William Case <billlinux [ at ] rogers [ dot ] com> [071003 10:45]: > > I understand, that in reality, addresses for processes and parts of > > processes can be almost anywhere in RAM. But there is an organizing > > process that takes place in VM. Manuals and texts make reference to > > fixed locations for things like BIOS code. Others show programs as > > being at a base address with consecutive lines of code being offset. I > > would like to see how all of this gets represented in a organized > > logical fashion on a running machine. > > On x86 we have this legacy crap shoot called the BIOS. It's horrible > and disgusting, and it ain't going away. > > Here is what the simple layout looks like... > > http://www.osdata.com/system/physical/memmap.htm Thanks. Shows layouts for DOS and MAC. I assume that re: Bios Linux OS would be the same as DOS, because the code is stored before any OS begins ?? > > ... but since the early nighties (when the above was everything you > needed to know) it's gotten worse. Now USB, ACPI, ATA, VIDEO, and other > parts of the BIOS reserve various regions. > > INT 0x15, service 0xE820, was added for OS software to get the layout of > usable memory on the system. This will list about 5 regions reserved to > different parts of the BIOS. It also lists the physical memory regions > that the OS can use for whatever it wants. > Write a small C program to get access to this table/layout -- I assume ?? > Some of the physical address regions will be listed in /proc/iomem. > > > I know I can get addresses etc. with self-written C programs. I was > > just wondering if there exits a nice little gui program (but command > > line will do) that shows me where (at what addresses) different things > > are being stored. > > When you write C programs on an OS, you will be executing in virtual > memory. Which has nothing to do with physical layout. Each 32bit > application gets 4G of memory space to play with, even if there isn't > that much actual memory available. > Didn't know that. Will pick it up in my reading I am sure. > > first and last address of my memory, > > BIOS that has been written to memory, > > Kernel space, > > User space, > > shell, > > processes (running and sleeping), > > The above is not how you want to look at things. User space runs in > virtual memory, which is seldom contiguous in physical memory. Understood. But nonetheless I had hoped there was some organized fashion by which it could be invisioned. > So you > can exclude all of that. You need to get a book on memory architecture > (or read the recent article series at LWN http://lwn.net/Articles/250967/). Am doing. > > > I would like to see start and end addresses for the above. > > I would probably only look one or two times and then be content. > > I tried to cat /sys/* and cat /proc/* but couldn't find anything useful, > > but that doesn't mean its not there. > > If you're interested in one application's virtual memory maps you can > look at /proc/$$/smaps, where $$ could be any replaced with pid. Will check it out. Sigh. I was just hopping someone had taken the time to put it together a representation of total memory use and organization much the same way the gparted gui was created to produce a graphic representation of a hard drive. Oh, well. -- Regards Bill