Hello, Jon Masters wrote: >> There is, of course, no reason to change modprobe; just define the current >> behaviour that the *last* alias is preferred, and generate modules.alias >> accordingly. > > For now, let's base it on Modules.order but ensure the alias file is > written in the appropriate order (I need to check, that's probably in > reverse of Modules.order...I'll think about this tomorrow, this has been > on my mind recently, and like I said, I had to kludge a fix for an > Enterprise distribution for deterministic behavior recently too). > >> Jon's idea of having the later one pull the device away would also work, but >> seems like it's a complex solution to a corner case. > > Well, ultimately, we (myself, Kay, and others) would seem to prefer that > rebinding be done properly - so through a combination of udev rules and > kernel behavior, the user/third parties define the priorities. We should > load all the drivers - that's totally correct - but we shouldn't depend > upon whichever probe function will run first, that's too lame. It is lame but works for most of the cases. I'm not sure whether full-fledged fine-grained driver selection would be an unnecessary overkill or not. > I'll start with the simple fix, then we should debate this... Yeap. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
