v1: https://www.redhat.com/archives/libvir-list/2017-September/msg00103.html

Changes since v1:

 Split into 3 parts... The first patch would be the bare minimum using
 STRPREFIX instead of STREQ type comparisons for the incoming path to
 be "/dev/cdrom[N]" or "/dev/srN" (or resolved to that).

 This would "work" for the most part, but then since it's possible to 
 make even more checks let's check against the collected node device
 data. Patch 2 therefore will "tag" the already collected cdrom data
 with a capability. This allows patch3 to find any/all CDROM's on the
 host and compare the resolved path to that list of devices returning
 "true" if something matches a node device declared physical CDROM.

I split things up mainly to make it easier to decide whether patch 1
is sufficient or not. If patch2 and patch3 are OK, I would also add
a release note indicating the improvement to find CDROM by node device
capability.  It's a separate "improvement" on it's own as well. Whether
it's truly useful or not, is a different question...

John Ferlan (3):
  qemu: Be more selective when determining cdrom for taint messaging
  nodedev: Add capability bit to detect 'cdrom' devices
  qemu: Add inquiry to nodedev for cdrom taint checking

 include/libvirt/libvirt-nodedev.h    |  1 +
 src/conf/node_device_conf.c          |  6 ++-
 src/conf/node_device_conf.h          |  5 ++-
 src/conf/virnodedeviceobj.c          | 21 ++++++++--
 src/node_device/node_device_driver.c |  1 +
 src/node_device/node_device_udev.c   |  2 +
 src/qemu/qemu_domain.c               | 78 +++++++++++++++++++++++++++++++++++-
 src/qemu/qemu_domain.h               |  2 +
 src/qemu/qemu_driver.c               |  4 +-
 src/qemu/qemu_process.c              |  2 +-
 tools/virsh-nodedev.c                |  3 ++
 tools/virsh.pod                      |  2 +-
 12 files changed, 116 insertions(+), 11 deletions(-)

-- 
2.9.5

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 09/11/2017 04:32 PM, John Ferlan wrote:
> v1: https://www.redhat.com/archives/libvir-list/2017-September/msg00103.html
> 
> Changes since v1:
> 
>  Split into 3 parts... The first patch would be the bare minimum using
>  STRPREFIX instead of STREQ type comparisons for the incoming path to
>  be "/dev/cdrom[N]" or "/dev/srN" (or resolved to that).
> 
>  This would "work" for the most part, but then since it's possible to 
>  make even more checks let's check against the collected node device
>  data. Patch 2 therefore will "tag" the already collected cdrom data
>  with a capability. This allows patch3 to find any/all CDROM's on the
>  host and compare the resolved path to that list of devices returning
>  "true" if something matches a node device declared physical CDROM.
> 
> I split things up mainly to make it easier to decide whether patch 1
> is sufficient or not. If patch2 and patch3 are OK, I would also add
> a release note indicating the improvement to find CDROM by node device
> capability.  It's a separate "improvement" on it's own as well. Whether
> it's truly useful or not, is a different question...

[1]

> 
> John Ferlan (3):
>   qemu: Be more selective when determining cdrom for taint messaging

ACK to this one ^^

>   nodedev: Add capability bit to detect 'cdrom' devices
>   qemu: Add inquiry to nodedev for cdrom taint checking

However, these two ^^ look like an overkill to me. It's still just a
taint message that nobody cares about. Or?
1: Yeah, I don't think we really need such a big hammer for tiny nail.
But I might be missing something.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 09/18/2017 09:12 AM, Michal Privoznik wrote:
> On 09/11/2017 04:32 PM, John Ferlan wrote:
>> v1: https://www.redhat.com/archives/libvir-list/2017-September/msg00103.html
>>
>> Changes since v1:
>>
>>  Split into 3 parts... The first patch would be the bare minimum using
>>  STRPREFIX instead of STREQ type comparisons for the incoming path to
>>  be "/dev/cdrom[N]" or "/dev/srN" (or resolved to that).
>>
>>  This would "work" for the most part, but then since it's possible to 
>>  make even more checks let's check against the collected node device
>>  data. Patch 2 therefore will "tag" the already collected cdrom data
>>  with a capability. This allows patch3 to find any/all CDROM's on the
>>  host and compare the resolved path to that list of devices returning
>>  "true" if something matches a node device declared physical CDROM.
>>
>> I split things up mainly to make it easier to decide whether patch 1
>> is sufficient or not. If patch2 and patch3 are OK, I would also add
>> a release note indicating the improvement to find CDROM by node device
>> capability.  It's a separate "improvement" on it's own as well. Whether
>> it's truly useful or not, is a different question...
> 
> [1]
> 
>>
>> John Ferlan (3):
>>   qemu: Be more selective when determining cdrom for taint messaging
> 
> ACK to this one ^^
> 
>>   nodedev: Add capability bit to detect 'cdrom' devices
>>   qemu: Add inquiry to nodedev for cdrom taint checking
> 
> However, these two ^^ look like an overkill to me. It's still just a
> taint message that nobody cares about. Or?
> 1: Yeah, I don't think we really need such a big hammer for tiny nail.
> But I might be missing something.
> 
> Michal
> 

I agree with you, but just in case someone wanted to use that sledge
hammer in order to catch some really obscure corner condition, I figured
I'd show it was possible...

Still I can give it a few more days to see if someone indicates they
would also like to see usage of the sledge hammer.

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list