Bug 1212295
| Summary: | [lshw] type "display" should be "VIDEO" | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Dan Callaghan <dcallagh> |
| Component: | inventory | Assignee: | beaker-dev-list |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Dan Callaghan <dcallagh> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | aigao, dcallagh, ebaak, mjia |
| Target Milestone: | 21.0 | Keywords: | Patch, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-26 06:18:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 541294 | ||
|
Description
Dan Callaghan
2015-04-16 06:26:12 UTC
(In reply to Dan Callaghan from comment #0) > For example from a physical x86 system: > > ES1000 1002:515E > type should be: VIDEO > > Probably just need to do a straightforward translation of display->video in > beaker-system-scan. smolt is using [1] to map the class code. This device class code is 0x03 which should be mapped as "Display controller", so I think using "display" here is more accurate. [1] https://www-s.acm.illinois.edu/sigops/roll_your_own/7.c.1.html (In reply to matt jia from comment #1) > (In reply to Dan Callaghan from comment #0) > > For example from a physical x86 system: > > > > ES1000 1002:515E > > type should be: VIDEO > > > > Probably just need to do a straightforward translation of display->video in > > beaker-system-scan. > > smolt is using [1] to map the class code. This device class code is 0x03 > which should be mapped as "Display controller", so I think using "display" > here is more accurate. It's not just about accuracy. It's also about not breaking existing filters. So, if somebody had a filter looking for video, we still want that to work.. (In reply to Amit Saha from comment #2) > (In reply to matt jia from comment #1) > > (In reply to Dan Callaghan from comment #0) > > > For example from a physical x86 system: > > > > > > ES1000 1002:515E > > > type should be: VIDEO > > > > > > Probably just need to do a straightforward translation of display->video in > > > beaker-system-scan. > > > > smolt is using [1] to map the class code. This device class code is 0x03 > > which should be mapped as "Display controller", so I think using "display" > > here is more accurate. > > It's not just about accuracy. It's also about not breaking existing filters. > So, if somebody had a filter looking for video, we still want that to work.. hmm, what kind of filters ? some filters like the ones in host-filters? (In reply to matt jia from comment #3) > (In reply to Amit Saha from comment #2) > > (In reply to matt jia from comment #1) > > > (In reply to Dan Callaghan from comment #0) > > > > For example from a physical x86 system: > > > > > > > > ES1000 1002:515E > > > > type should be: VIDEO > > > > > > > > Probably just need to do a straightforward translation of display->video in > > > > beaker-system-scan. > > > > > > smolt is using [1] to map the class code. This device class code is 0x03 > > > which should be mapped as "Display controller", so I think using "display" > > > here is more accurate. > > > > It's not just about accuracy. It's also about not breaking existing filters. > > So, if somebody had a filter looking for video, we still want that to work.. > > hmm, what kind of filters ? some filters like the ones in host-filters? And I think we should encourage users to update their existing filters with the Device classes of lshw because they are well documented. I donnot think using translations is a good idea from the long-term prospective. As far as I can tell these device classes are not standardised anywhere, they were just made up by smolt and by lshw. But from a Beaker user's point of view they are not "smolt device classes", nor "lshw device classes", they are essentially "Beaker device classes". So we can either say that the "Beaker device class" of VIDEO is now being renamed to DISPLAY and make all our users adjust their filters to account for that -- and then we have to do something about all the existing VIDEO devices in the database -- or we can just update beaker-system-scan to map DISPLAY to VIDEO, and nothing changes from the Beaker point of view. The latter option seems like the right approach. Btw we seem to have a case mismatch, we may need to do something about that for consistency. Lookups against the db should be case-insensitive but for consistency in display we probably want to map all device classes to uppercase in beaker-system-scan as well. (In reply to Dan Callaghan from comment #5) > As far as I can tell these device classes are not standardised anywhere, > they were just made up by smolt and by lshw. But from a Beaker user's point > of view they are not "smolt device classes", nor "lshw device classes", they > are essentially "Beaker device classes". > > So we can either say that the "Beaker device class" of VIDEO is now being > renamed to DISPLAY and make all our users adjust their filters to account > for that -- and then we have to do something about all the existing VIDEO > devices in the database -- or we can just update beaker-system-scan to map > DISPLAY to VIDEO, and nothing changes from the Beaker point of view. The > latter option seems like the right approach. +1 for the second approach. > > Btw we seem to have a case mismatch, we may need to do something about that > for consistency. Lookups against the db should be case-insensitive but for > consistency in display we probably want to map all device classes to > uppercase in beaker-system-scan as well. Separate patch: http://gerrit.beaker-project.org/#/c/4244/ Beaker 21.0 has been released. |