<div dir="ltr">On 9 January 2014 20:19, Brian Schott <span dir="ltr"><<a href="mailto:brian.schott@nimbisservices.com" target="_blank">brian.schott@nimbisservices.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Ian,<div><br></div><div>The idea of pci flavors is a great and using vendor_id and product_id make sense, but I could see a case for adding the class name such as 'VGA compatible controller'. Otherwise, slightly different generations of hardware will mean custom whitelist setups on each compute node.  </div>

</div></blockquote><div><br></div><div>Personally, I think the important thing is to have a matching expression.  The more flexible the matching language, the better.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style="word-wrap:break-word">On the flip side, vendor_id and product_id might not be sufficient.  Suppose I have two identical NICs, one for nova internal use and the second for guest tenants?  So, bus numbering may be required.  <div>

<br></div><div><div>01:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900 GTX] (rev a1)<br></div><div></div><div>02:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900 GTX] (rev a1)<br>
</div>
</div></div></blockquote><div><br></div><div>I totally concur on this - with network devices in particular the PCI path is important because you don't accidentally want to grab the Openstack control network device ;)<br>

 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div><div>I know you guys are thinking of PCI devices, but any though of mapping to something like udev rather than pci?  Supporting udev rules might be easier and more robust rather than making something up.</div>

</div></blockquote><div><br></div><div>Past experience has told me that udev rules are not actually terribly good, which you soon discover when you have to write expressions like:<br><br> SUBSYSTEM=="net", KERNELS=="0000:83:00.0", ACTION=="add", NAME="eth8"<br>

<br></div><div>which took me a long time to figure out and is self-documenting only in that it has a recognisable PCI path in there, 'KERNELS' not being a meaningful name to me.  And self-documenting is key to udev rules, because there's not much information on the tag meanings otherwise.<br>

<br>I'm comfortable with having a match format that covers what we know and copes with extension for when we find we're short a feature, and what we have now is close to that.  Yes, it needs the class adding, we all agree, and you should be able to match on PCI path, which you can't now, but it's close.<br>

-- <br></div><div>Ian.<br></div><br></div></div></div>