lkml.org 
[lkml]   [2002]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectUsing "query_module"
Date

Please personally CC me with responses on this posting:

I would like to use the "query_module" system call with the QM_SYMBOLS flag
in an application, but I am not sure of what the appropriate way of doing it
is, and whether it is safe.

I have the man-page for query_module on the system on which I am compiling,
but I can't find the function prototype in <linux/module.h>. So, I just
wrote the prototype in my code. Is this the way this should be done?

Other than that, the man page states that struct module_symbol looks like
this:
struct module_symbol
{
unsigned long value;
unsigned long name;
};

But in module.h it is defined as:
struct module_symbol
{
unsigned long value;
const char *name;
};

From my understanding, the second definition is the way the kernel uses this
struct, and the first definition is the way the user should interpret the
result of query_module with the QM_SYMBOLS flag. Am I right? (Shouldn't
there be 2 different structures for this?)

Most importantly, I would like to understand whether it is safe to use this
system call. If I compile my application on a machine in which this function
is implemented (in libc), is the system call guaranteed to work on kernels
2.2 and up? Do I need to do a preliminary check such as "if
(query_module(NULL, 0, NULL, 0, NULL))" for the existence of the system
call, or would it simply fail if I use it regularly?

Thanks for your help,
Zvi.

---------------
Zvi Vlodavsky
Software Engineer
Network Communications Group, Intel Corp.
Zvi.Vlodavsky@intel.com

Disclaimer: In this e-mail, I do not speak on behalf of Intel corp.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.052 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site