coldplugging & modules

Matthew Burgess matthew at linuxfromscratch.org
Wed Jul 14 12:22:33 PDT 2004


<cut from the thread "Some notes on Testing">

<summary>
Apparently /proc will revert to being used solely for process
information, and cease to provide hardware info under /proc/bus/[bus]. 
Matt is clueless how this may or may not affect coldplugging based
hardware detection in the (probably fairly distant) future.
</summary>

On Wed, 14 Jul 2004 19:29:10 +0100
Ian Molton <spyro at f2s.com> wrote:

> On Wed, 14 Jul 2004 17:43:55 +0100
> Matthew Burgess <matthew at linuxfromscratch.org> wrote:
> 
> > Now, as Kevin explained, as long as
> > the *bus* drivers are loaded (which implies they should *never* be
> > modules) 
> 
> why? A bus is a device - it will appear as a device on some other bus,
> and can be loaded at will.
> 
> no problem.

OK, I know this is going to sound flippant, but surely the IDE bus
support has to be compiled in (assuming you're not running SCSI) of
course.  I mean, you're never going to get the module loaded if the IDE
bus isn't available (and you're not doing initrd type stuff).  So,
taking it one stage past that, we'll assume the IDE bus is up and we
have access to whatever device has the modules on it.

We now want to get soundcard support up, and I happen to have a PCI
card.  Now, the soundcard driver and the PCI bus drivers are compiled
as modules.  Under the proposed usage of /proc, /proc/bus/pci won't be
available.  /sys/bus/pci won't be available either as the module
hasn't been loaded yet, hence sysfs information is currently
unavailable for it. How will coldplugging cope with this? How will it
know I've got a PCI bus that it needs to scan?  Maybe it'll resort to
'/lib/modules/`uname -r`/modules.pcimap?  Or maybe, as you state above,
the PCI bus is actually on another bus - if so I'm genuinely interested
in knowing what bus this is, and how far up the chain this goes - I'm
thinking there's got to be a top-level to this tree at some point?

Thanks for your patience with me on this,

Matt.



More information about the lfs-dev mailing list