<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Any thoughts on this? Good Idea? Worth doing?<br></blockquote></div><br>To be honest, I do not see the real simplification in that many changes. Spreading black- and/or white-lists over so many places seems rather confusion to me. I agree that using devnode names is not ideal for the reasons you mentioned. That was done mainly to have an internal blacklist of known devices that are known not to work. Potentially this could be a device type (= driver name?). But would this not also be possible as a new element of the blacklist? 
E.g.:<br><br>blacklist {<br>    driver fd<br>    driver device-mapper<br>    ...<br>}<br><br>The problem with the current implementation, in my thinking, is that we have a dependency between two sections (blacklist and blacklist_exceptions) and the keywords within. Without reading any further
<br>documentation it seems awkward that it is not possible to blacklist device nodes and punch holes by certain wwid numbers. When I think about it, I guess (any other opinions welcome) that a exception is what is really intended to be used. So that should always have more priority than a blacklist. So if the filter finds a matching entry in the blacklist_exceptions section, the device should be used.
<br><br>So my proposal would be:<br><br>1. process the blacklist_exceptions (any match enables the device)<br>2. process the blacklist<br>3. any device dropping through is also used.<br><br>Additionally I like the idea of a match-by-driver extension.
<br><br>Stefan<br>