On Sunday 13 April 2008, Tejun Heo wrote: > Please be advised that some modern controllers are dual interfaced. > Native one and legacy one. The legacy one is SFF compliant and > depending on configuration may appear at legacy IO addresses, so if you > aren't careful, you can end up with two drivers driving the same > hardware which usually doesn't end too well. Loading generic drivers > w/o knowing that it's needed is quite dangerous. I would strongly > advise against it. I totally agree. The problem being discussed here is exactly how to know it is needed. If you have better suggestions for that, I'd appreciate it. As you specifically say "modern controllers", I suspect that the problem is limited as I guess those are fairly unlikely to be found in machines that have an ISA bus. I also think the way I've implemented in the Debian installer should be relatively safe: 1) ide-generic is only loaded _after_ any otherwise detected modules 2) it is only loaded if an ISA bus is present 3) it is only included in the initrd for the installed system if loading it in the installer resulted in additional block devices appearing I would unload ide-generic in the installer if no additional block devices appear, but unfortunately that's not possible as it is marked "permanent". By loading it after any other drivers I expect there will be no issues during the installation (as the other driver will already have claimed the device). Making sure it is only loaded for the installed system if actually needed should avoid problems there. ATM I can only see this causing problems in systems that need both ide-generic and some other driver as adding ide-generic in the initrd is likely to result in it being loaded before that other driver. Again, if anyone has a better suggestion how to implement this (preferably without asking the user whether he has a device that needs ide-generic, which most users are unlikely to know anyway), I'd appreciate it. Cheers, FJP -- 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
