<br><br><div><span class="gmail_quote">2007/11/9, Benjamin Marzinski <<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<snip>.<br><br>If I recall correctly, blacklist exceptions were originally proposed as<br>a solution to the problem of not being able to remove the bl_product<br>lines from the default device configuration, without reentering the
<br>whole configuration for that device.  They were specifically designed so<br>that you could still blacklist the device by wwid and devnode rules.</blockquote><div><br>The blacklist exceptions originally  were introduced as  both: a solution to remove a product blacklist without having to specify the other pre-defined settings and a way to enable some devices specifically without having to create a blacklist with holes in it.
<br>The way this currently works is a bit surprising. Although there are comments in the annotated config file these are easily missed and this probably should be improved. At the moment devnode black and whitelist has a higher priority than wwid and wwid a higher priority than product blacklist. This means, if you have a devnode blacklist that matches a device, the wwid black and whitelist is never considered.
<br>What would work is to blacklist all wwid's and then whitelist the ones that should be used. Usings wwid's instead of the devnodes has the advantage that these are consistent, regardless of the order the devices are added.
<br>I am not quite sure which way is better. Should we change the code so a whitelisting is always preceding a blacklist entry or is there a way to point out that there is a certain workflow and mixing devnode and wwid black and whitelists is not working well? Personally I would go for the first option.
<br><br></div></div><br>Stefan