Re: [Gumstix-users] Problems including <linux/module.h>

[Dave H. <dhy...@gm...>]

HI Adam,

On 2/7/07, Adam McLeod <mcl...@gm...> wrote:
> On 2/7/07, Dave Hylands <dhy...@gm...> wrote:
>
> > So, as far as I know you don't have to do anything. When you say you
> > include module.h, do you mean from a usr mode app or from kernel side?
>
> I mean that the beginning of my C++ program has the line "#include
> <linux/module.h>" in it.

As a general rule, you can't include kernel headers from usermode
apps. There are a few exceptions.

> > Attempting to load a module which isn't present just causes modprobe
> > to produce an error, it isn't fatal.
>
> I'm not running modprobe.  I want to programatically check to see if
> the module is present at runtime.

What if the driver was compiled in statically? What you really want to
know is if i2c-dev support is available.

If you're using udev, then you could just check for the presence of
/dev/i2c-0 If it isn't there then the driver isn't running (either by
being statically linked into the kernel or by a loadable module).

If you really insist on knowing whether a module is loaded or not,
then you can open the file /proc/modules. There is a line for each
module loaded. If you see the one you're looking forit's loaded.

A much better way (IMHO) is to just try and open /dev/i2c-0. If it
succeeds then the driver is available (statically or loaded via
module). If the open fails, then the driver isn't available.

> > Similarly, trying to open /dev/i2c-0 when the i2c-dev module isn't
> > loaded also just causes open to get an error, again it isn't fatal.
>
> Ah, but if my program does not take action in response to the module
> being missing, it will generate a fatal error.

Only if your code takes a fatal action. Failing to open due to a
missing module is not a fatal error. It just causes the open to return
with -1 and errno set to ENODEV.

> My program uses a set of threads that depend on one another to
> function.  One of these threads uses the I2C bus.  If the modules
> aren't installed, I shouldn't create any of the set.  I suppose I
> could run a test wherein I open and close the device, and use that as
> a substitute for just checking for the presence of the modules.

Yep - especially since checking for the modules is really the wrong thing to do.

> However, if the modules are present and the device cannot be opened,
> then the program should rightly terminate with an error.  So I figured
> the 'correct' way to write the program would involve both types of
> test.

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/