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

[salsaman at xs4all.nl]

On Tue, November 16, 2010 14:34, damion.yates at gmail.com wrote:
> 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
>
>


OK, yes. I did find the proper solution eventually, which is to use ioctls
on the various /dev/videoX devices.

Regards,
Salsaman.


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