[Gllug] How to check if module is in kernel ?

[damion.yates at gmail.com]

On Tue, 16 Nov 2010, Jon Masters wrote:

> On Mon, 2010-11-15 at 21:55 +0000, Richard Jones wrote:
> 
> > The original poster needs to go ahead and use the API, and provide
> > suitable messages from the errors returned if it fails.
> 
> And also to articulate what is missing. I know the module tools can do
> with some further features, etc. and I'd like to know what he wants. I
> could, for example, add an option to lsmod to display built-in vs. out
> of tree modules, etc. etc. it's pretty easy to do.

OYG!  Please implement this.

Whilst it's obvious that coding to use a modules capabilities and
dealing with errors is a reasonable way to detect if that module is in
some way in the kernel (either via a loadable module or built in), it
would be extremely handy for a shellscript called binary like lsmod to
simply state yes or no, as to the availability of said module/builtin.

Otherwise you'd end up with all the 1000s of application writers having
to write small capability checking binaries for their install scripts.
Their main app itself might not be the best place for this, if for
example it requires a listening $DISPLAY or is linked against a
gazillion other complex libs/dependancies that also/haven't yet been
checked as part of the install.

In my experience IDE-using application developers are often not the type
who want to get bogged down in sysadmin style tasks of helping inform a
user at install/run time whether they need to insmod something (assuming
auto dependancy stuff isn't possibly, or setup well, which is
understandable).

Distribution maintainers and sysadmins are usually better at this sort
of thing and they'll need something like a version of lsmod that tells
you if stuff is compiled in.

For the OP, there are of course several states to deal with:

- It's compiled in, stuff should work without you having to inform the
  user to do anything.

- It's loaded as a module, stuff should work without you having to
  inform the user to do anything.

- It's neither built in, nor loaded in.  User needs to do an insmod and
  stuff works.  This might be if the module can't be auto-loaded.

- It's neither built in, nor loaded in.  Nor was it compiled with the
  kernel and so doesn't exist and needs compiling against this kernel.
  In some cases that isn't going to be possible, due to various other
  kernel options chosen, to compile it as a module at all.

Rich's solution will only catch the 1st two positively, leaving you
unable to know what to do next.

In the case of the v4l stuff, it is _extremely_ unwise to not use
loadable modules, as you quite often need to pass extra and varying
params depending on the devices you're plugging in - I'm not even sure
they'll all worked compiled in anymore.  Only overly security conscious
admins, or old-timers, or people building firewalls are likely to have a
kernel that can't load modules and has everything statically linked in.
vloopback, being a v4l thing, is as mentioned, almost certainly not
going to be compiled in by any distribution maintainer.

Damion
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug