hello sir,
PROBLEM::How to call a function in a module from the
kernel code ??
what we did ? ::
we wanted to call a function in our module ll from
shm.c file (which is in the kernel)
so we declared function pointer in shm.c
:: unsigned long long (*ptr1)(int)
we declared it as extern in shm.h
:: extern unsigned long long (*ptr1)(int)
then we declared also in our module (ll)
:: extern unsigned long long (*ptr1)(int)
we initialized it to ptr1 = commun; in init module
of ll.c
where commun is we wanted to call from the kernel
but it gave an error as undefined refernce to ptr1
when we inserted our module..
can you help on this thing or can you give us a
example
regarding how it is done ??
waiting for a reply
plz cc to [email protected]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Thursday 09 February 2006 20:25, you wrote:
>
> hello sir,
>
> PROBLEM::How to call a function in a module from the
> kernel code ??
>
> what we did ? ::
> we wanted to call a function in our module ll from
> shm.c file (which is in the kernel)
>
> so we declared function pointer in shm.c
> :: unsigned long long (*ptr1)(int)
>
> we declared it as extern in shm.h
> :: extern unsigned long long (*ptr1)(int)
>
> then we declared also in our module (ll)
> :: extern unsigned long long (*ptr1)(int)
>
> we initialized it to ptr1 = commun; in init module
> of ll.c
> where commun is we wanted to call from the kernel
>
> but it gave an error as undefined refernce to ptr1
> when we inserted our module..
>
> can you help on this thing or can you give us a
> example
> regarding how it is done ??
EXPORT_SYMBOL(ptr1);
--
Greetings Michael.
On Feb 09, 2006, at 14:25, omkar lagu wrote:
> hello sir,
>
> we wanted to call a function in our module ll from shm.c file
> (which is in the kernel)
>
> so we declared function pointer in shm.c
> unsigned long long (*ptr1)(int)
>
> we declared it as extern in shm.h
> extern unsigned long long (*ptr1)(int)
>
> then we declared also in our module (ll)
> extern unsigned long long (*ptr1)(int)
>
> we initialized it to ptr1 = commun; in init module of ll.c where
> commun is we wanted to call from the kernel
>
> but it gave an error as undefined refernce to ptr1 when we inserted
> our module..
>
> can you help on this thing or can you give us a example regarding
> how it is done ??
It would help a lot if you could post a link to your source code.
Let me point out (in case you don't know this already) that if you do
what you describe and distribute the result, you are automatically
licensing your ll.c file under the GPLv2. By distributing a
derivative of both the Linux kernel and your proprietary module (You
are taking Linux kernel sources and modifying them explicitly for
your module), the result must be GPL. Also, I think what you are
describing is basically impossible. I believe what you want to do is
this:
/* in shm.c */
unsigned long long (*ptr1)(int);
EXPORT_SYMBOL(ptr1);
However this makes it impossible to reliably remove your module,
because a process could race entering the function as the module
loader is trying to remove the module.
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare
On Thu, 9 Feb 2006, Kyle Moffett wrote:
> It would help a lot if you could post a link to your source code.
Not really. The question is pretty straight forward, so no source is
really necessary. Are you just asking this because you want to stress the
next point.
> Let me point out (in case you don't know this already) that if you do
> what you describe and distribute the result, you are automatically
> licensing your ll.c file under the GPLv2. By distributing a
> derivative of both the Linux kernel and your proprietary module (You
> are taking Linux kernel sources and modifying them explicitly for
> your module), the result must be GPL.
Well, just because something is under the GPL, doesn't mean you need to
post a link for all to have. You only need to give the source to those
that you distribute it to. For example, if you give GPL code to someone
that paid a hell of a lot to get it (the distribution, not paying for the
code) then those that have paid might not want to give it away either. So
yes, you can have closed GPL if all that get the binary and code don't
distribute it to anyone else. Of course once one that has it does give it
away (since no one can prevent them from doing so) then the code will be
opened.
> Also, I think what you are
> describing is basically impossible. I believe what you want to do is
> this:
>
> /* in shm.c */
> unsigned long long (*ptr1)(int);
> EXPORT_SYMBOL(ptr1);
>
> However this makes it impossible to reliably remove your module,
> because a process could race entering the function as the module
> loader is trying to remove the module.
Not really impossible. As I have done in my (yes GPL) logdev module
http://www.kihontech.com/logdev/logdev-2.6.15-rt16.patch
I have a "hooks" file that has all the functions I need for the loadable
module. But to call any of the hooks, you must call wrapper functions
that grabs a spinlock before calling the function. This spinlock is also
used to reset the function pointer when removing the module. Yes, I know
that this is inefficient, but when the module is compiled into the kernel,
those wrapper functions also turn into direct functions without the need
of the spinlock, or redirected function pointers.
-- Steve
On Feb 10, 2006, at 02:55, Steven Rostedt wrote:
> On Thu, 9 Feb 2006, Kyle Moffett wrote:
>
>> It would help a lot if you could post a link to your source code.
>
> Not really. The question is pretty straight forward, so no source
> is really necessary. Are you just asking this because you want to
> stress the next point?
No, not at all! I suspect there is possibly/probably a better way to
do what the OP wants. Also, the particular example of putting a
pointer to a module function into the kernel core is quite racy and
hard to get the locking/memory-barriers correct for, so a review of
that part would probably be useful to the poster.
>> Let me point out (in case you don't know this already) that if you
>> do what you describe and distribute the result, you are
>> automatically licensing your ll.c file under the GPLv2. By
>> distributing a derivative of both the Linux kernel and your
>> proprietary module (You are taking Linux kernel sources and
>> modifying them explicitly for your module), the result must be GPL.
>
> Well, just because something is under the GPL, doesn't mean you
> need to post a link for all to have.
Oh of course not, but that's not what I was saying. I just wanted to
clarify that such deep linkage into the kernel implied that the full
terms of the GPL applied to any distribution.
>> Also, I think what you are describing is basically impossible. I
>> believe what you want to do is this:
Oops, this isn't what I meant to say. I meant that it's _possible_
but hard to get correct.
>> /* in shm.c */
>> unsigned long long (*ptr1)(int);
>> EXPORT_SYMBOL(ptr1);
>>
>> However this makes it impossible to reliably remove your module,
>> because a process could race entering the function as the module
>> loader is trying to remove the module.
>
> Not really impossible. As I have done in my (yes GPL) logdev
> module http://www.kihontech.com/logdev/logdev-2.6.15-rt16.patch
> I have a "hooks" file that has all the functions I need for the
> loadable module. But to call any of the hooks, you must call
> wrapper functions that grabs a spinlock before calling the
> function. This spinlock is also used to reset the function pointer
> when removing the module. Yes, I know that this is inefficient,
> but when the module is compiled into the kernel, those wrapper
> functions also turn into direct functions without the need of the
> spinlock, or redirected function pointers.
This is precisely why I asked the original poster to send a link to
code (doesn't have to be the whole thing, but even just the pertinent
snippets of the module code). You or I (or anybody else whose reading
this thread) could easily help them verify their locking and pointer
usage.
Cheers,
Kyle Moffett
--
I lost interest in "blade servers" when I found they didn't throw
knives at people who weren't supposed to be in your machine room.
-- Anthony de Boer