Greetings,
I'm coding an application that messes with modules a lot, and I've
stumbled upon a query_modules syscall in my docs. Later I've found out
that the docs come from modutils and that module-init-tools doesn't seem
to document (any of) the syscalls.
May I then ask, why is the query_module syscall gone? And more
importantly, what replaces it, if anything? It seems to me that parsing
the /proc/modules is not only less comfortable, but according to the
very obsolete manpage I have, it also can provide less information.
For exmaple I'm not aware of anything like QM_SYMBOLS on per-module
basis like it was (do correct me if I am wrong, it'd simplify my work a
lot), ... and getting QM_REFS for example requires extensive parsing of
/proc/modules.
Thanks in advance for reply.
- iSteve
On Fri, 9 Sep 2005, iSteve wrote:
> Greetings,
> I'm coding an application that messes with modules a lot, and I've
> stumbled upon a query_modules syscall in my docs. Later I've found out
> that the docs come from modutils and that module-init-tools doesn't seem
> to document (any of) the syscalls.
>
> May I then ask, why is the query_module syscall gone? And more
> importantly, what replaces it, if anything? It seems to me that parsing
> the /proc/modules is not only less comfortable, but according to the
> very obsolete manpage I have, it also can provide less information.
>
> For exmaple I'm not aware of anything like QM_SYMBOLS on per-module
> basis like it was (do correct me if I am wrong, it'd simplify my work a
> lot), ... and getting QM_REFS for example requires extensive parsing of
> /proc/modules.
>
> Thanks in advance for reply.
>
> - iSteve
The newer modutils package doesn't use query_modules and calling
that function will return -ENOSYS in 'modern' kernels. The
latest modutils becomes very sparse because most of the module
functionality got moved into the kernel where it expanded, err,..
don't get me started. Anyway, your user-mode interface is now
/proc/modules. It does provide a bit more information than
before, but as you noticed, it sucks^M^M^M^M^Mis not nice.
Have fun!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Drat, that's a pity, the interface seemed pretty neat and usable (from
my rather linux-kernel-newbie point of view, anyway:), especially neater
than parsing a file.
Why did the query_module get removed, by the way? (I searched lkml, but
lkml.org search on 'query module' or 'query_module' didn't really give
me any relevant hits).
- iSteve
linux-os (Dick Johnson) wrote:
> On Fri, 9 Sep 2005, iSteve wrote:
>
>
>>Greetings,
>> I'm coding an application that messes with modules a lot, and I've
>>stumbled upon a query_modules syscall in my docs. Later I've found out
>>that the docs come from modutils and that module-init-tools doesn't seem
>>to document (any of) the syscalls.
>>
>> May I then ask, why is the query_module syscall gone? And more
>>importantly, what replaces it, if anything? It seems to me that parsing
>>the /proc/modules is not only less comfortable, but according to the
>>very obsolete manpage I have, it also can provide less information.
>>
>> For exmaple I'm not aware of anything like QM_SYMBOLS on per-module
>>basis like it was (do correct me if I am wrong, it'd simplify my work a
>>lot), ... and getting QM_REFS for example requires extensive parsing of
>>/proc/modules.
>>
>>Thanks in advance for reply.
>>
>> - iSteve
>
>
> The newer modutils package doesn't use query_modules and calling
> that function will return -ENOSYS in 'modern' kernels. The
> latest modutils becomes very sparse because most of the module
> functionality got moved into the kernel where it expanded, err,..
> don't get me started. Anyway, your user-mode interface is now
> /proc/modules. It does provide a bit more information than
> before, but as you noticed, it sucks^M^M^M^M^Mis not nice.
> Have fun!
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
> I apologize for the following. I tried to kill it with the above dot :
>
> ****************************************************************
> The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
>
> Thank you.
iSteve <[email protected]> wrote:
> May I then ask, why is the query_module syscall gone? And more
> importantly, what replaces it, if anything?
I don't know query_module, but ls -laR /sys/module might do the job.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
I'm aware of the sysfs interface -- but neither /proc/modules nor
/sys/module/ actually really supplement the query_module api...
- iSteve
Bodo Eggert wrote:
> iSteve <[email protected]> wrote:
>
>
>> May I then ask, why is the query_module syscall gone? And more
>>importantly, what replaces it, if anything?
>
>
> I don't know query_module, but ls -laR /sys/module might do the job.
Okay, so, I have so far gathered:
- the whole module interface change between 2.4 and 2.6 was because
some security concerns, most of the stuff (loading module etc.) moved
towards kernel
- query_module is gone, there is no syscall similar in function but
with different name
- losing of query_module also prevents binary-only modules
(guesswork@work)
- /proc/modules and /sys/module interface doesn't by far supply what
query_module could do
My questions are:
a) Are my observations correct? Where did I go wrong?
b) Is there any planned replacement of query_module, or extendind sysfs
or procfs module interface?
c) Wouldn't revamping query_module also allow binary-only modules,
therefore easier decisions for vendors, whether to support Linux?
Thanks in advance and sorry for these probably quite silly questions.
- iSteve
On Tue, 13 Sep 2005, iSteve wrote:
> Okay, so, I have so far gathered:
>
> - the whole module interface change between 2.4 and 2.6 was because
> some security concerns, most of the stuff (loading module etc.) moved
> towards kernel
I thought it was due to raciness or locking concerns, but
I'm not sure about that.
> - query_module is gone, there is no syscall similar in function but
> with different name
Right.
> - losing of query_module also prevents binary-only modules
> (guesswork@work)
Nope, they are not prevented. However, there is a Tainted flag
that is set when one is loaded (and that flag is never cleared).
> - /proc/modules and /sys/module interface doesn't by far supply what
> query_module could do
Can you state succinctly exactly what you are trying to do?
> My questions are:
> a) Are my observations correct? Where did I go wrong?
> b) Is there any planned replacement of query_module, or extendind sysfs
> or procfs module interface?
Haven't heard of one.
> c) Wouldn't revamping query_module also allow binary-only modules,
they are still possible.
> therefore easier decisions for vendors, whether to support Linux?
>
> Thanks in advance and sorry for these probably quite silly questions.
>
> - iSteve
--
~Randy
> Nope, they are not prevented. However, there is a Tainted flag
> that is set when one is loaded (and that flag is never cleared).
>
Okay, I've been wrong in my conclusion and I gotta read some fine manual
about how the modules actually work -- could you recommend me some in
particular?
>> - /proc/modules and /sys/module interface doesn't by far supply what
>>query_module could do
>
> Can you state succinctly exactly what you are trying to do?
I would like to be able to query symbols of a loaded module, get list of
and list of dependencies of loaded module from an app, preferably
without having to parse a file...
On Tue, 13 Sep 2005, iSteve wrote:
> > Nope, they are not prevented. However, there is a Tainted flag
> > that is set when one is loaded (and that flag is never cleared).
> >
>
> Okay, I've been wrong in my conclusion and I gotta read some fine manual
> about how the modules actually work -- could you recommend me some in
> particular?
Nope, there is precious little doc about modules, especially
in 2.6.
There is a FAQ, but I doubt that it answers many of your
questions.
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/FAQ
You could try LDD3, but I don't see much there that would help
you either.
http://lwn.net/Kernel/LDD3/
> >> - /proc/modules and /sys/module interface doesn't by far supply what
> >>query_module could do
> >
> > Can you state succinctly exactly what you are trying to do?
>
> I would like to be able to query symbols of a loaded module, get list of
> and list of dependencies of loaded module from an app, preferably
> without having to parse a file...
No, no syscall to do that. Looks like it will require reading
and parsing files.
And you answered my "what" question clearly, so I have one more.
Why? for what purpose, to what end? What are you tring to
accomplish?
Thanks,
--
~Randy
On 9/13/05, iSteve <[email protected]> wrote:
> > Nope, they are not prevented. However, there is a Tainted flag
> > that is set when one is loaded (and that flag is never cleared).
> >
>
> Okay, I've been wrong in my conclusion and I gotta read some fine manual
> about how the modules actually work -- could you recommend me some in
> particular?
>
Well, the depmod(8), lsmod(8), insmod(8), modprobe(8), modules.dep(5),
depmod.old(8) and modprobe.conf(5) man pages all have various bits of
info.
There's also some info in chapter 2 of "Linux Device Drivers, Third
Edition" - http://lwn.net/images/pdf/LDD3/ch02.pdf
Then there's The Linux Kernel Module Programming Guide -
http://www.tldp.org/LDP/lkmpg/2.6/html/
As well as the Linux Loadable Kernel Module HOWTO -
http://www.tldp.org/HOWTO/Module-HOWTO/
Also take a look at the file Documentation/kbuild/modules.txt in your
kernel source dir.
That's just a little bit of reading material for you :)
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
>>I would like to be able to query symbols of a loaded module, get list of
>>and list of dependencies of loaded module from an app, preferably
>>without having to parse a file...
>
>
> No, no syscall to do that. Looks like it will require reading
> and parsing files.
>
> And you answered my "what" question clearly, so I have one more.
> Why? for what purpose, to what end? What are you tring to
> accomplish?
The files so far provided still do not seem to give these informations
though...
Part of the project I'm working on -- click-click ui for handling
modules, with some perks: in this case, getting info about loaded
modules that I hoped to obtain via query_module.
Oh, and one more question: There were no particular issues with
query_module, or were they? If there weren't, why wasn't it kept?
On Tue, 13 Sep 2005, iSteve wrote:
> >>I would like to be able to query symbols of a loaded module, get list of
> >>and list of dependencies of loaded module from an app, preferably
> >>without having to parse a file...
> >
> >
> > No, no syscall to do that. Looks like it will require reading
> > and parsing files.
> >
> > And you answered my "what" question clearly, so I have one more.
> > Why? for what purpose, to what end? What are you tring to
> > accomplish?
>
> The files so far provided still do not seem to give these informations
> though...
Right, I don't see dependency ("requires") info there, just "using" info.
> Part of the project I'm working on -- click-click ui for handling
> modules, with some perks: in this case, getting info about loaded
> modules that I hoped to obtain via query_module.
>
> Oh, and one more question: There were no particular issues with
> query_module, or were they? If there weren't, why wasn't it kept?
I don't recall.
You can try searching the lkml archives or asking Rusty Russell:
MODULE SUPPORT
P: Rusty Russell
M: [email protected]
L: [email protected]
S: Maintained
One quick search produced this, but it doesn't help you any:
http://marc.theaimsgroup.com/?l=linux-kernel&m=108355087015676&w=2
--
~Randy
On Tue, 13 Sep 2005, iSteve wrote:
> Part of the project I'm working on -- click-click ui for handling modules,
> with some perks: in this case, getting info about loaded modules that I hoped
> to obtain via query_module.
>
> Oh, and one more question: There were no particular issues with query_module,
> or were they? If there weren't, why wasn't it kept?
I think it wasn't kept because it would have had to get rewritten anyway,
and the only user (modutils) was going away. Most of the information was
only there because the old system needed it, and the new system didn't
need it, so nobody bothered. Also, the modern style is to avoid
special-purpose syscalls and use sysfs. It probably wouldn't be too hard
to get the information exported through the sysfs interface if you ask
Rusty and explain exactly what you need.
(Note that you can get module symbols by searching /proc/kallsyms for
<tab>[<name>], so that part is available from the kernel, although not
efficiently if you have a lot of symbols that you aren't interested in)
-Daniel
*This .sig left intentionally blank*