<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Um. Mostly because I just thought up this idea to address the issues you had with my first idea. I though it would be nice if multipath had a clearly defined set of devices it didn't need to bother checking, and then it would only need to look at the filter rules after all the path information had been gathered. However, you are correct. Multipath can just check the blacklist_driver rules at the beginning of the filter section before gathering path information, and the rest of the rules afterwards, to achieve the same effect. As a side note, blacklist_driver should also allow the special string "*", which blacklists all devices. Also, whitelist_driver rules don't make any sense.</blockquote><div> I tried to avoid having multiple filter-defining sections but I must admit having everything in one section might be confusing as well. The problem is, that there are three stages at which a decission has to be made to continue or not. First by driver or node name (Kiyoshi has a valid argument there). Every match at this early stage prevents useless work. Whitelist rules for driver and devnode make sense if internal rules have to be reversed ( e.g. internal blacklist uses blacklist_driver "*"). Second stage is to check whether it makes sense to continue with a certain class of devices (from vendor, model). At this point I do not think it makes sense to look at the driver and devnode rules again. And finally, if the UID information has been gathered, there would be the moment to check which of them should be used. When the current code does the final filtering it goes again through all stacked filters and by that a whitelist for a devnode(range) cannot be limited by a wwid blacklist. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There are some minor issues that crop up, if we do away with invalid_drivers. Without the invalid_drivers section, the current default devnode blacklist rules would turn into blacklist_driver rules that were automatically appended to the beginning of the filter section. The</blockquote> <div> Not appended at the beginning, because that could never be changed by user-specified rules. Everything pre-defined would have to get appended after the user defined list. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> users' inability to whitelist certain devices seems like it would be less obvious in this situation than it would be if there was a specific section for invalid devices. But this does seem to be a pretty minor fault. As a side note, the product_blacklist rules would still need to become blacklist_device rules that are appended to the end of the filter section, so it is possible to override them.</blockquote><div> Yes. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There is also the issue of how to keep multipath from doing anything. Currently, you need to use blacklist { devnode "*" } to keep multipath from doing anything to your devices. Unfortunately, if you use the following blacklist { wwid "*" } it doesn't keep multipath from touching your devices (for instance, the getuid callout is still run on them), although customers might naively think that it should. With invalid_drivers, it is obvious how to keep multipath from touching the devices. Without it, you are forced to do</blockquote><div> Not if devnode (and driver) rules are checked before the other rules. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> filter { blacklist_driver "*" }</blockquote><div> </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If I understand what your idea is, I'm not sure that it's what we want to do. In my mind, any of the following filters should allow you to create a multipath device for the device with the wwid "foo" </blockquote><div> I admit my idea had a major flaw. It is just not compatible with the way device detection is run. It might turn out that the only thing that has to be changed is to change which filter rules are used at a certain point of the detection. Decide which device to ignore at all: - look at the whitelist entries for devnode (and driver), continue to check if found - look at the blacklist entries for devnode (and driver), do not use if found - no match, continue Decide for which devices to call getuid: - look at the whitelist entries for device, continue to check if found - look at the blacklist entries for device, do not use if found - no match, continue Decide which UIDs should be used: - look at the whitelist entries for wwid, use if found - look at the blacklist entries for wwid, do not use if found - no match, use device </div></div> Stefan