> > This doesn't handle the common case of adding another card of the
> > same type as already exist in the system. In that case if you don't
> > want to redesign the driver interface you have to remove the driver,
> > reconfigure, and then install the driver again.
>
> Perhaps, then, we need to redesign the driver interface - whether we like it or
> not is irrelevant.
I agree. I also think that modules that support hot plug devices should
export an ioctl, callback routine, or such so that we can let the driver
know when it's about to have a card yanked. Without changing the driver
interface we don't gain much since we have to unload and reload the
driver (not a pretty thing).
The IRIX driver model would be nice for this-- the driver loads without
attaching any devices. The kernel then invokes the driver's attach()
routine for each device that the driver wants to claim. If devices
are added, attach() is called at that time; if devices are removed,
detach() is called then. The mechanism also supports partial unloading
of unused modules (usually after 5 min) if the device has not been
accessed recently.
>
> Currently, module loading is user-initated. Modules are loaded and hardware
> probed for when a userspace program attempts to use a device.
>
> I suggest that we should do this the other way round - hardware-initiated.
> Rather than waiting for a user to access the device, we scan the busses and
> load drivers for all the hardware we find attached.
The stub driver, yes. Then invoke attach() when the device is actually
accessed.
>
> In the kernel, we keep a mapping for each bus type from vendor/device ID (or
> their equivalent) to the driver routine which can handle those devices -
> much like CardBus and PCMCIA already does.
>
Exactly.
> This only needs to be done for drivers which are actually loaded - then when
> we discover a device which isn't in this list, we can use kmod to request a
> driver for it - request_module("pci_device_102b_1100") etc.
>
> Adding MODULE_SUPPORTED_HARDWARE entries to signify which devices are handled
> by each driver module is a fairly simple task while will keep depmod/modprobe
> happy.
>
> The only drawback I see with this is that it doesn't allow you to save kernel
> --
Go take a look at the IRIX device driver guide. You have to register
to get to it, but it's free registration and there is a lot of other
cool stuff there anyway. That is essentially what I'm proposing, though
I would like to add a parameter to attach() that includes the assigned
device's unit number (for the minor). It has to be done centrally
or things will break if two devices are attach()'d simultaneously.
http://developer.sgi.com
-- Eric Lowe FibreChannel Software Engineer, Systran Corporation elowe@systran.com"You can't spell failure without U-R-A." -Dispair.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/