On Mon, Nov 20, 2006 at 12:43:33PM -0500, Dominik Brodowski wrote: > As the matching by func_id is fuzzy and gives false positives, this is a > multiple-step process: > > a) the kernel checks all built-in and previously loaded modules for > prod_id and manf_id matches > > b) userspace (udev/hotplug + modprobe) loads appropriate modules (including > those which are only matched by func_id > > c) during the module initialization (e.g. modprobe hasn't returned yet) the > kernel checks the modules based on prod_id and manf_id matches > > d) after all these modprobe calls return, userspace writes "1" into > /sys/$devpath/allow_func_id_match. Then, the kernel re-checks all > built-in and previously loaded modules for func_id "fuzzy" matches. > > It is self-evident that steps b)-d) only work once userspace is ready. As > PCMCIA drivers should be able to work even before that, manf_id and prod_id > table entries do make sense even if func_id matching works. However, it doesn't scale. You're going to be forever adding entry after entry after entry to drivers. It's a never-ending job. Of course, it's really up to you whether you want this task. 8) -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
