home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] Help with the use of 'lsof' ??

Thanks Martin,

I am sorry it has taken a few days to respond, but the holidays got in
the way.


On Wed, 2005-12-21 at 11:57 -0500, Martin Hicks wrote:
> On Wed, Dec 21, 2005 at 11:41:40AM -0500, William Case wrote:

> no.  You really can't see what's going on in kernel space.  that's by
> design.  i guess you could read /dev/mem, but that's discouraged.
> 

I tried $cat /dev/mem in gterm (gnome terminal) and got gibberish.  I
will try it in VT and in runlevel 3 and to see if can view anything
meaningful.

> > With that said, I would like to see the files that exist after bootup in
> > memory (VM) starting at Ox00000000 including BIOS space, kernel space
> > and the top of user space (essential user programs, but not necessarily
> > running applications). Is this even possible?
> 
I've read about 'dmidecode' and 'biosdecode' that might give some info
about BIOS in memory.

> Not really. Things like BIOS don't map into the memory map.  Why would
> you even want to see such things? Its going to be 4G of data on x86
> (ignoring High Mem).  Its going to be mostly meaningless.
> 
Answer below.

> > I plan to build a diagram for myself of what is normally in memory.  I
> > am not afraid of too much detail, but I want to be sure I've got
> 
> You can say block chunks and figure it out in general.  Like, you should
> be able to figure out where in the virtual address space certain
> libraries are mapped by the dynamic loader.
> 
> You can also say, in general, where things are in kernel memory (i.e.,
> certain areas are reserved for vmalloc, memory mapped registers, etc,
> etc.)
> 
[snip]

I am trying to save myself some work if its unnecessary.  I could (and
will if I have to) paste together the information from different manuals
and texts as you suggest.  But I would have thought that a visualization
of the contents of memory would be so rudimentary to understanding Linux
that someone would have created such a picture or, better still, created
a program or other means to see the total memory picture in individual
computers.

You ask above why I would want to do such a thing?  I, like a lot of
people, think visually the easiest.  If I can put an image in my mind, I
can call on it whenever I am trying to understand anything involving
computer memory.  In fact, by using mental images, I can come to
understand things without any real feats of memory.  

I understand that any such diagram at best would only be an abstraction
and would not reflect the reality of physical or virtual memory.  I also
understand that there is an interactive hierarchy of memory that
includes registers, L1 cache, L2 cache, virtual memory, physical memory
and the hard disk, floppies, tapes etc..

However, things happen in a pattern that can be generalized and
imagined.

BIOS gets loaded in a specific order and moved; the kernel gets loaded
in a specific order, tables and data structures are created and gets
moved around; specific amounts of memory space are created; initial user
programs like the shell get loaded; later user applications get added to
the memory.  I would like to look closer at what these files or buffers
are.

Short of analyzing each and every BIOS code, kernel function, table or
data structure, everything in user space, there has to be an easier way.

Suggestions on how I might research and draw such a memory map would be
greatly appreciated.  It only has to be done once, the final diagram and
or tools used can be made available to others who have the same type of
view of the world that I do.

Regards Bill