lk 2.5.49 module frustration

Hopefully others are having more success with the new module loader than I am. My system is basically RH8.0 with the new module-init-tools (version 0.7) loaded and the recent 2.5.49 kernel.

During system load there is noise (failure?) on calls to modprobe since the new command doesn't support the same switches as the old. [harmless?]

My lsmod looks like this:

# lsmod
Module                  Size  Used by
scsi_debug             29423  0 [unsafe]
ohci1394               21561  0
ieee1394               41773  1 ohci1394 [unsafe]
parport_pc             18883  0 [unsafe]
parport                30228  1 parport_pc [unsafe]
ehci_hcd               32801  0
usbcore                90237  3 ehci_hcd

Those "unsafe" dependencies wedge in a module, making it hard to remove them. In the case of scsi_debug about 30 seconds after it is loaded I get this on my console:
# Module scsi_debug cannot be unloaded due to unsafe

# usage in fs/proc/inode.c:204
That is procfs calling __MOD_INC_USE_COUNT. Is that our
problem (i.e. shouldn't RR fix that before he lets this
stuff loose on us)?

Are all the MODULE_* macros now dead? I can no longer get any load time options/parameters through to the scsi_debug. Nothing useful comes out of modinfo.

Where is the ..... documentation?

$ ls -l modules.txt
-rw-r--r--    1 1046     101          9441 Feb 17  2001 modules.txt

Quoted 8 lines · Douglas Gilbert

Hopefully others are having more success with the new module loader than I am. My system is basically RH8.0 with the new module-init-tools (version 0.7) loaded and the recent 2.5.49 kernel.

During system load there is noise (failure?) on calls to modprobe since the new command doesn't support the same switches as the old. [harmless?]

It doesn't yet. It's intended to.

Quoted 11 lines

My lsmod looks like this:

# lsmod
Module                  Size  Used by
scsi_debug             29423  0 [unsafe]
ohci1394               21561  0
ieee1394               41773  1 ohci1394 [unsafe]
parport_pc             18883  0 [unsafe]
parport                30228  1 parport_pc [unsafe]
ehci_hcd               32801  0
usbcore                90237  3 ehci_hcd

Quoted 8 lines

Those "unsafe" dependencies wedge in a module, making it hard to remove them. In the case of scsi_debug about 30 seconds after it is loaded I get this on my console:
# Module scsi_debug cannot be unloaded due to unsafe

# usage in fs/proc/inode.c:204
That is procfs calling __MOD_INC_USE_COUNT. Is that our
problem (i.e. shouldn't RR fix that before he lets this
stuff loose on us)?

I posted a patch for this almost a week back. It didn't get picked up, so I put this particular fix into my tree that I uploaded and announced today.

Quoted 3 lines

Are all the MODULE_* macros now dead? I can no longer get any load time options/parameters through to the scsi_debug. Nothing useful comes out of modinfo.

Yes, it's very much a work in process, not a completed change over. Rusty has publically stated that he thinks he bit off more than he can chew and I know he's taken a lot of flak over this change. However, there *are* positive parts to Rusty's work and it does in fact solve the races he says it solves (at least once you convert things like fs/proc/inode.c to know about the fact that getting a module *can* fail) and as soon as you get the remaining parts of the kernel to properly grab module references when calling into a module. Myself and Cristoph already did that basic job for the SCSI layer.

Quoted 5 lines

Where is the ..... documentation?

$ ls -l modules.txt
-rw-r--r--    1 1046     101          9441 Feb 17  2001 modules.txt

Yes, that's another thing that isn't complete.