Re: [rtl] runtime image of module

["Norm Dresner" <ndrez@att.net>]

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