Re: xxxVERBOSE module?
On Sat, 22 May 2010, John Nemeth wrote:
} (referring to loading the pciverbose module...)
} I guess I can probably remove those changes. So we'll have to rely on
Although, you can't test them, possibly keep them. We do want to
support hotswap PCI at some point.
It turns out that I need to keep them after all! Without an explicit
load, the modules don't get initalized until much later in system
startup, and this module beomces rather useless. :)
There is still one problem, though. As you (John) pointed out earlier,
we don't have any accessible filesystems from which to load modules.
But unfortunately, the kern_module subsystem doesn't seem to realize
this. So, if the pci code requests the module to be loaded, and the
module is neither built-in nor provided by the boot loader, it _will_
attempt to load from the filesystem. I expected it to fail, but the
failure mode is rather ungraceful - the kernel panics with backtrace
_atomic_inc_32
namei + x109
vn_open + x84
kobj_load_vfs + x82
module_load_vfs + x2cf
module_do_load + 3e9
module_load + x68
It would seem to me that somewhere in this mess we should simply return
ENOENT (or some other appropriate errno).
Also, dyoung@ is in the process of
merging cardbus into PCI. I don't know if your changes would cause
mod_verbose to be autoloaded for cardbus, which uses PCIVERBOSE, but
cardbus insertion should be handled at some point. And, of course,
there is PCIe and expresscard on the horizon. expresscard is basically
hotswap PCIe along with USB (i.e. an expresscard slot brings out
signals for both and the card determines which one it is going to
use).
Both of these will be reasonable. I've already updated all the cardbus
references to the pci_find{vendor,product} routines, so it would be a
simple matter of making the pciverbose module gets (re)loaded.
What about X? What does it use for scanning the PCI bus?
I suspect it uses libpci - I'll be doing a full-tree search for libpci
shortly.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: Kernel modules - documentation?
On Sep 5, 6:12pm, Paul Goyette wrote: } } Is there any documentation on the modules interface or API? There does } not seem to be anything in the man pages... I'm not aware of any. Probably the best documentation for the moment is src/sys/modules/example/example.c. This is an example of a very simple module, but it has all the pieces. You might also want to look at modctl(2), which is the syscall that modload/modstat/modunload call. I should probably add some cross references. } My specific questions: } } What actually triggers an autoload of a module? (There seem to be very } few places where module_autoload() is called.) This depends on the type of module, i.e. filesystem modules are handled differently from device driver modules. Basically the part of the kernel that needs functionality that might be provided by a module needs to check to see if the functionality is currently available and if it isn't, then it needs to call module_autoload() for the appropriate module. } What is the semantic difference between module_autoload() and a "normal" } module_load()? From the module's perspective, there is none. More generally, the kern.module.autoload sysctl will be checked to see if module autoloading is allowed, there are restrictions on the path passed to module_autoload(), and a timer will be kicked off to try to automatically unload the module. } Does the code which calls either of these routines need to be concerned } with whether the module has been previously loaded? Is it OK to load a } module that has already been loaded? You will get EEXIST if the module is already loaded. Also, if it is a built-in module then autoload will fail. It can only be reloaded by doing 'modload -f '. } Given that there is a kernel thread that runs around and attempts to } unload any unreferenced modules that have been loaded "for a while", is } it ever necessary or desirable to explicitly unload a module? Code that autoloads a module doesn't need to worry about this. } What happens if a global symbol referenced by a module doesn't exist? } Does the module get loaded anyway, leaving the reference unresolved? It will fail to link and thus will fail to load. I don't know the exact error that you will get off hand. It was ENOENT, but there was talk about changing it to ENOEXEC. I will check on this, and if it hasn't been done yet, I'll probably make the change. }-- End of excerpt from Paul Goyette
Re: xxxVERBOSE module?
On Sep 6, 10:07am, Paul Goyette wrote: } On Fri, 21 May 2010, John Nemeth wrote: } } > } My current approach is to load the module right before the first pcibus } > } is enumerated, and unload when finished. So we can use the in-kernel } > } >File systems aren't initialised during autoconf when the system is } > being cold booted, thus it isn't possible for the kernel to load a } > module at that point in time. Also consider that on most platforms } > with PCI, prior to the first pcibus being enumerated, the kernel } > doesn't know anything about any disk drives that may be attached to the } > system. } } Ah, yeah! Ooppss! :) } } I guess I can probably remove those changes. So we'll have to rely on Although, you can't test them, possibly keep them. We do want to support hotswap PCI at some point. Also, dyoung@ is in the process of merging cardbus into PCI. I don't know if your changes would cause mod_verbose to be autoloaded for cardbus, which uses PCIVERBOSE, but cardbus insertion should be handled at some point. And, of course, there is PCIe and expresscard on the horizon. expresscard is basically hotswap PCIe along with USB (i.e. an expresscard slot brings out signals for both and the card determines which one it is going to use). } > } The fun part is making sure that the shared code still plays nicely with } > } src/lib/libpci :) } > } > I don't know anything about libpci, but have fun with that. } } The only thing I find that uses libpci is /usr/sbin/pcictl and that } seems to be working fine. What about X? What does it use for scanning the PCI bus? }-- End of excerpt from Paul Goyette
