[lug] logging missing 2.6 kernel modules

[Lee Woodworth]

In reviewing the hotplug and udev stuff, I was reminded of
some things I have seen on the web that apply:

   Kernel version 2.6 will not automaticlly load device drivers
   when a related device node is accessed. The major reason
   being that there is interest in having device major/minor
   become dynamially allocated. For example the device mapper
   (dm_mod) already uses a dynamic minor number for
   /dev/mapper/control.

You may be interested in this excerpt from the udev FAQ:

   Q: But udev will not automatically load a driver if a /dev node is opened
      when it is not present like devfs will do.
   A: If you really require this functionality, then use devfs.  It is still
      present in the kernel.

   Q: But wait, I really want udev to automatically load drivers when they
      are not present but the device node is opened.  It's the only reason I
      like using devfs.  Please make udev do this.
   A: No.  udev is for managing /dev, not loading kernel drivers.

   Q: Oh come on, pretty please.  It can't be that hard to do.
   A: Such a functionality isn't needed on a properly configured system. All
      devices present on the system should generate hotplug events, loading
      the appropriate driver, and udev will notice and create the
      appropriate device node.  If you don't want to keep all drivers for your
      hardware in memory, then use something else to manage your modules
      (scripts, modules.conf, etc.)  This is not a task for udev.

If you can issue modprobe's from the shell and the device works, try
adding these commands to /etc/modprobe.conf:
   options joydev .....
   alias /dev/js0 joydev
I don't think this will get the module loaded at boot, it just configures
what happens when a modprobe of joydev occurs.

You need to find where your init system looks for modules to modprobe
during system start. I would suggest starting with
   grep --recursive modprobe /etc/*
to see what scripts invoke modprobe. Then see what files they read/source.
There might be something in /etc/sysconfig for RH/Fedora systems.


D. Stimits wrote:
> David Anselmi wrote:
> 
>> D. Stimits wrote:
>>
>>> It used to be that on a 2.4 kernel an attempt to use a device that
>>> did not have a proper kernel driver would yield a message, e.g.,
>>> something like "no module for net-pf-10"...I forget that particular
>>> one was something like an apple printer protocol. I'm trying to get
>>> the sblive game port to load automatically on a 2.6 kernel and FC2.
>>
>>
>>
>> Not sure I'm much help, but here's what I know.
>>
>> Are you using udev?  That's a new way to manage /dev entries--instead
>> of listing everything possible it only lists things that exist (have
>> hardware and have a module).
> 
> 
> An interesting thing when looking at the 2.6 Pseudo filesystems menu, it
> shows the option for the old devfs as /dev, and marks it obsolete, which
> I have NOT enabled (I've always avoided devfs like the plague, and do
> not want to use udev either until I know it really works)...I would
> expect udev to be in this same menu area but it is not. Kernel docs just
> call it hotplug as the replacement, which I know I have, because USB
> plugins generate a log message. My option for "Hotplug firmware loading
> support" (CONFIG_FW_LOADER) is set to module, but I have a feeling this
> is more to do with how it deals with hotplug device installs once it has
> detected the device, rather than the device detection.
> 
> On a side note, docs in 2.6.9 mention /proc/sys/kernel/hotplug, and
> indeed I have this file, the content properly points at /sbin/hotplug.
> With this file being generated by the kernel, it is yet more evidence
> that hotplug is supported. In any case I don't believe hotplug applies
> since the standard game port is not a hotplug device, and cannot
> generate hotplug events. Add to this that I have the files in /dev/, and
> they are static, never-changing, and much of this hotplug thing is to
> generate those files (not to load drivers...I suspect this would be a
> separate mechanism).
> 
>> So it used to be that you had a /dev node and "opening" it could clue
>> the kernel to load the driver.  Now there is no dev node and you need
>> something else to detect the hardware, load the module, and clue udev
>> to make a node for it.
> 
> 
> I have the node, it's static, no udev or devfs. The cable and connecter
> are standard game port.
> 
>> I think that something is hotplug.  Are you using that?  When the
>> kernel notices new hardware it runs hotplug, which loads the driver
>> and does whatever other configuration is required to use the device. 
>> That includes making the udev node.
> 
> 
> Have hotplug, but so far as I can tell hotplug is only related to
> hotplug type connections, e.g., USB, firewire, PCMCIA, such that older
> standard ports like serial and parallel ports, and game ports, would be
> unrelated.
> 
>> That's the way I understand it anyway.  So you might have to add some
>> stuff (udev, hotplug).
>>
>> Otherwise, there may be some way your distro autoloads modules.  In
>> Debian there's a /etc/modules file that lists modules that get loaded
>> automatically by an init script (a distro approved bogus rc.local
>> command).  Each module listed gets modprobed when the script runs.
> 
> 
> That's what I'm having a problem figuring out. The 2.6 kernel abandoned
> /etc/modules.conf, and added /etc/modprobe.conf. Hotplug takes care of
> pluggable devices on USB, firewire, and PCMCIA, but this is not one of
> those devices. On the other hand, hotplug detects device
> attachment/detachment, whereas I'm worried about a program doing the
> reverse: Attempting to use /dev/input/js0, to generate an event to load
> modules, rather than a connector based event.
> 
> Has anyone here at all ever succeeded on a 2.6 kernel with a sblive!
> game port to get it to auto load the right modules without a manual
> entry into rc.local? It seems like 2.6 has abandoned older devices.
> 
> D. Stimits, stimits AT comcast DOT net
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug