Re: [rtl] runtime image of module

[A V <anumula_rtl@yahoo.com>]

Hi,

     Thanks for your replies.
First let me tell what i am doing.
    As part of my thesis i am developing debugger for
realtime tasks. It should run in Real-time Kernel and
access the module of user interest and give
information of that module. 

    Regarding Kernel knowledge i have just studied
Memory management of Linux and some scheduling related
things. And i have idea of ELF format. To get
practical knowledge about ELF format i wrote some
simple programs to display various sections of an
executable file. 
I know how run-time memory image of an executable is 
formed.
    
     Now my problems are :
As Kernel modules are different from executable files
i need to know how its memory image will be. And one
more doubt is...
   I can get address of a module using query_module
system call. And i know that first 52 bytes of memory
image will be ELF header. So can i directly read 52
bytes beginning at that address ?

Once again thanks for nice replies.
Venkat


--- Norm Dresner <ndrez@att.net> wrote:
> Before anyone even begins to think about answering
> the
> question, we'd need to know why you want this
> information
> and how much you already understand about the
> kernel's
> internal architecture so the answer can be tailored
> appropriately.
> 
>     Norm
> 
> ----- Original Message -----
> From: Calin A. Culianu <calin@ajvar.org>
> To: <rtl@fsmlabs.com>
> Sent: Monday, November 05, 2001 11:29 AM
> Subject: Re: [rtl] runtime image of module
> 
> 
> > On Sun, 4 Nov 2001, A V wrote:
> > >
> > > Hi all,
> > >
> > >   I want to know how the runtime image of a will
> > > be.i.e where the stack will be and bss . Can
> somebody
> > > help me.
> >
> > All modules run in kernel space. This means that
> the
> address space of a
> > running module is the same logical address space
> that the
> kernel itself
> > uses -- this is because a module IS the kernel. 
> Memory
> for modules is
> > cleanly allocated during the module's creation and
> cleanly free'd during
> > the module's destruction. (with the exception for
> memory
> the module itself
> > explicitly allocates using kmalloc).
> >
> > As far as stacks go: Well, that depends... you may
> have
> several stacks if
> > you go and create yourself several threads inside
> your
> module.  The other
> > data and code segments and such all get allocated
> by the
> kernel in kernel
> > space via kmalloc probably during the
> create_module()
> system call. For
> > more info, module.c in the kernel/ subtree of the
> linux
> source tree can
> > answer many of your questions... :)
> >
> > As for where exactly stacks come from in the linux
> kernel
> when tasks run
> > on behalf of users or during bottom-halves of
> drivers:
> that's a good
> > question. I would imagine that actually there are
> fewer
> kernel stacks than
> > there are kernel tasks.  Most of the time tasks
> spend
> their time running
> > in user mode, where they get their own user
> stacks.. as
> for when they run
> > in kernel mode during system calls, they probably
> get
> these temporary
> > stacks that go away completely as soon as the
> system call
> returns to user
> > mode.
> >
> > I kind of wish I knew more about the kernel and
> the
> relationship between
> > different threads of execution and dedicated
> kernel
> tasks.... Oh well..
> > maybe someone else can shed more light on this
> matter...
> >
> > -Calin
> >
> >
> >
> >
> > >
> > > Regards
> > > Venkat
> 
> 
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail majordomo@rtlinux.org
> OR
> echo "unsubscribe rtl <Your_email>" | mail
> majordomo@rtlinux.org
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
> 


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com