https://bugzilla.novell.com/show_bug.cgi?id=221276 Summary: FATE #301145: ease providing new pci.ids Product: openSUSE 10.2 Version: Beta 2 plus Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: mjancar@novell.com ReportedBy: mjancar@novell.com QAContact: qa@suse.de When a KMP is supporting some new hardware unknown to lspci, hwinfo and similar tools, the corresponding vendors are getting support calls as the system is listing hardware components as 'unknown' which in the users eyes translates into "doesn't recognize my component!" possible solutions - update pci.ids frequently via maintenance - make /usr/share/pci.ids a symlink, define location for 'all of them' and allow packages to bring their own, curren tcopy. may come with pci.ids-lint tool to make sure file is always extended or corrected and know ids are not dropped. - modularize pci.ids file this is really annoying partners so I'd prefer to have a technical solution but it's not blocking operation. providing frequent maintenance updates of the pci.ids file until we have a sound solution in SP1 could make our partners happy. References: ~garloff/scripts/Python/merge-pciids contains my prototype for creating /usr/share/pci.ids The distributed (and updated via update-pciids) pci.ids file would be moved to /usr/share/pci.ids.d/pci.ids.dist. In that directory, all other pci.ids would be dropped, with a naming convention (RPMname) that should avoid conflicts. The used /usr/share/pci.ids file would be a %ghost in the filelist and built in %post of pciutils. Then we either play %trigger tricks or just require all KMPs that needs new pci.ids to call merge-pciids in their %post script. The prototype is operational and tested well -- only drawback might be that we require python on the platform. (But if some feels this is a problem, he can rewrite the script in a low level language.) Partner: Novell NDA: no NDA Discussion: #1: gp@suse.de (2006-08-28 16:18:26) [reply] Kurt, I believe you expressed interest to drive this as architect? We'll probably want to release this with a maintenance update rather sooner than later, not just SP1, if possible without undue risk/effor. #2: garloff@suse.de (2006-08-28 16:27:06) [reply] It is a cosmetic shortcoming. Nevertheless, we should not give any partner any excuse to not use the partner driver update process, so I'm all for working on a solution. I'll drive it. My preferred solution would be to modularize pci.ids, so make pcitutils read the IDs that a package (typically KMP) may put in files dropped in /usr/share/pci.ids.d/ in addition to the IDs in the classical /usr/share/pci.ids. This obviously needs some policy for how those files may be named and what contents might be allowed. We need to investigate whether this is feasible: If there are many other consumers of pci.ids except pciutils, then we may need to change the file to a symlink somewhere below /var/ that's constructed out of the pci.ids.orig file and all the additional files somewhere. The reconstruction would need to be done by a litte script invoked via rpm %post or %trigger sections. Comments? #3: froh@suse.de (2006-08-29 10:02:18) [reply] a very simple solution could be to move the pci.ids file into a separate subpackage and to move ownership to the ones in charge of the driver process then for KMPs that are within the process (silver level partner) we simply provide an update of that pci-ids package whenever needed. the helpfull contribution from engineering could be a pci-ids-lint that checks the pci-ids file is valid and that flags red yellow green which PCI ids have been removed, modified or added respectively. That makes it trivial enough to review the updated pci-ids file that is submitted by the partner #6: garloff@suse.de (2006-09-22 10:20:07) [reply] Susanne, your suggestion implies that every driver update that requires s new PCI ID, we'd issue a new pciids.rpm. I'm not sure this is a good idea. It also implies that all driver updates are done via the ones in charge of the driver process -- a restriction that we did not want to build into the process. #8: froh@suse.de (2006-09-22 15:47:13) [reply] Indeed some partners will provide their KMPs on their own, didn't think of that. Then that leaves us with modularizing the pci.ids file. Would you prefer constructing a pci.ids file from pci.ids.d/* and leaving utilities allone? that would also stay compatible with partner tools that we are not awae of. Or would you prefer the utilities to use some libpciids to merge them on the fly? #10: garloff@suse.de (2006-09-25 18:14:28) [reply] Just merging them is easiest and least risky. I have a prototype ready for this (python script). #7: garloff@suse.de (2006-09-22 10:45:47) [reply] Does not look too bad: g32:/ # for name in /sbin/* /bin/* /lib64/* /usr/lib64/* \ /usr/bin/* /usr/sbin/* /usr/X11R6/bin/* /usr/X11R6/lib64* \ /opt/gnome/lib64/* /opt/gnome/bin/* /opt/kde3/lib64/* \ /opt/kde3/bin/*; do echo -en "\r$name: "; \ strings $name | grep pci.ids; done /sbin/lspci: /usr/share/pci.ids /sbin/setpci: /usr/share/pci.ids /sbin/update-pciids: SRC="http://pciids.sourceforge.net/v2.2/pci.ids" DEST=/usr/share/pci.ids /usr/bin/systool: /usr/local/share/pci.ids /usr/sbin/hald: /usr/share/pci.ids pci_ids_load /usr/sbin/s2ram: /usr/share/pci.ids: /usr/sbin/sysp: /usr/local/share/pci.ids So on first sight it would seem that only pciutils and hald would need to be adapted. Question remains whether we could do such a thing for old products -- or whether we better dynamically construct the classical pci.ids here. #4: kukuk@suse.de (2006-08-30 13:32:06) [reply] I hope everybody is aware of /sbin/update-pciids, which for example could be called by the post install script of KMP packages? #5: garloff@suse.de (2006-09-22 10:18:09) [reply] /sbin/update-pciids will pull the latest pci.ids from sourceforge. So it would only serve its purpose if the new IDs have been merged upstream when the driver is installed. Not sure whether that limitation is a problem. A more serious drawback is that it would result in the file /usr/share/pci.ids not being clean any more w.r.t. the RPM database. #9: froh@suse.de (2006-09-22 15:48:51) [reply] That would require access to sourceforge at the time the KMP is installed. I doubt this is alwasy the case. I'd rather prefer to bring the updated pci.ids along. #11: kukuk@suse.de (2006-10-09 15:04:27) [reply] I don't like the approach of merging pci.ids files from other ones. We know that this very problematic and in the end we will get yet another SUSEconfig script to do the job. Please enhance the pciutils to support a /usr/share/pci.ids.d/ directory. There third party vendors can drop in their files and this problem of having an inconsistent pci.ids file is solved for all time. #12: agruen@suse.de (2006-10-09 16:11:39) [reply] I agree with the /usr/share/pci.ids.d/ approach. #13: garloff@suse.de (2006-10-09 23:02:44) [reply] Well, with the merging approach, you would still just drop files into /usr/share/pci.ids.d/ directory (with some naming convention to avoid conflicts). The only difference is that you'd build the classic pci.ids file from pci.ids.dist and the (other) files in /usr/share/pci.ids.d/ so noone that happens to assume the existence of this file will fail. The downside is that you need to call the merge-pciids program in the %post section of pciutils and of every KMP that drops a file there. (Well, you might be able to play %trigger tricks alternatively ...) Not requiring the merge-pciids is certainly more elegant -- but that looks to risky an option for OLD distributions. I'm happy to be convinced otherwise. #14: kukuk@suse.de (2006-10-11 11:18:54) [reply] We know that %trigger tricks will not work and that, at the end, we will need yet another SuSEconfig script, about which people will complain and which will not be called in all cases, means the file is out of sync. #15: garloff@suse.de (2006-10-22 00:30:11) [reply] I fail to see a need for a SUSEconfig script. Just call it from %post in pciutils and every KMP that drops a file into /usr/share/pci.ids.d/. (And from the update-pci-ids script.) As it's in the own interest of the KMP providers to have the ability to drop pci ids there and that's not possible today, we just need to document that except for dropping a file (with a to be defined naming convention) they also have to put the call in the %post section of the RPM, otherwise it won't work for them. No chance for hidden failure. #16: garloff@suse.de (2006-10-22 00:39:44) [reply] Thorsten, we need to come to an agreement how to best proceed, otherwise we won't make any progress. The reasoning is known: Just having pciutils read from multiple files is the more elegant.solution, as you don't need to keep derived files in your filesystem that way that could become stale. That would be a code change to pciutils that we should get upstream. Question is whether we'd want tot touch released products (SLES10 and possibly also SLES9). The advantage of a merge script (which I have a working implentation for in python) is that it does not touch pciutils code. Only update-pci-ids would be changed to overwrite pci.ids.dist and the spec files would get added calls in %post. Advantage is that you preserve the existence of a complete pci.ids file, so anyone who uses it (outside of pciutils?) has the full information as well. Disadvantage is that you'd end up with having data twice on the system. And possibly issues with keeping things up-to-date. As Thorsten and I don't seem to be able to agree, I'd like to find a way forward to come to a decision. Should the dist meeting decide. The TPM meeting? Or simply Gerald and Thorsten? And I'd certainly like to hear from the package maintainer about the effort and the chances to get a pciutils code change upstream. #17: mjancar@suse.cz (2006-10-23 14:22:59) [reply] The way to go is IMHO /usr/share/pci.idsd.d/ for (vendor) packages, user defined entries and updates from the sf.net, and /usr/share/pci.ids as the default that nothing (except pciutils-ids package update) should touch, with the former taking precedence when they conflict about an entry. As I know the pciutils author personaly I don't expect much problems getting this upstream. #18: garloff@suse.de (2006-10-27 01:37:16) [reply] OK, what you describe still allows the merge with a script/tool or a merge inside pciutils. I assume you prefer the pciutils merge -- it certainly is the architetually nicer approach. Are you able to implement it? #19: kukuk@suse.de (2006-10-27 12:24:51) [reply] Marian, can you please look at this and speak with the upstream maintainer? I have a short proof of concept patch for this, but it does not work yet with compressed file support enabled (trivial to fix) and id_insert() always reports the entry was already added. I don't understand why, here somebody with more time need to look at it. #20: kukuk@suse.de (2006-10-27 13:56:59) [reply] ~/Export/pciutils-pci.ids.d.diff contains my current diff, the id_insert() duplicate problem is fixed, file compression is still disabled. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.