On Mon, Mar 30, 2015 at 08:55:22AM +0200, Greg KH wrote: > On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote: > > On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote: > > > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote: > > > > The macros in pci_ids.h are pretty useful for userspace > > > > using the pci sysfs interface. > > > > At the moment userspace is forced to duplicate these macros > > > > (e.g. QEMU does this), it is better to expose them in > > > > /usr/include/linux/pci_ids.h so everyone can just include > > > > this header. > > > > > > > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > > --- > > > > include/linux/pci_ids.h | 2998 +----------------------------------------- > > > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++ > > > > > > No, please use the pci ids file from the upstream pci id database > > > instead. > > > > > > > We shouldn't be putting these all in one file, > > > > pci.txt says: > > Please add PCI_VENDOR_ID_xxx for vendors > > You want to change this policy, and get rid of > > vendor ids in pci_ids.h completely? > > Please read the top of pci_ids.h. It hasn't had new ids added to it in > a long time. OK, looks like pci.txt should be fixed then. > > Bjorn, what do you think of this? > > > > > and pulling > > > them out of drivers isn't ok. > > > > This patchset is not pulling any files out of drivers fwiw. > > It did for the USB gadget driver patch that I commented on. > > > > Userspace shouldn't need to know any of these, use libpci. > > > > Unless I'm mistaken, libpci does not export a header with defines. It > > has a text file pci.ids, but parsing that when all I want is e.g. locate > > all intel devices is just too much overhead. No one wants that, so > > people just duplicate headers. > > Why would userspace need the pci id of anything? Look at how they are used e.g. by QEMU, seabios, gpxe. People want to say e.g. "find all network class devices". > Again, just use > libpci, isn't it fast enough? Don't duplicate existing logic. This really depends on whether you want something else that libpci provides. But if I just want e.g. standard class IDs, I don't want to depend on libpci. > Or use the hw database that libudev exports, which is already on your > machine and exports all of the pci ids from libpci directly. Same argument really. > > Standard class IDs are even sillier to duplicate. > > Again, why does userspace need this? > > thanks, > > greg k-h Mostly because it has a userspace driver, or is emulating a hardware device. For example, the VFIO driver uses the PCI hardware formats as it's userspace/kernel interface. This means I need a ton of PCI constants in userspace. Most of them are already in pci_regs.h, and so exported. No problem here. However class and prog interface IDs are not, they are in pci_ids.h Would you support splitting pci_ids.h to include/uapi/linux/pci_ids.h with standard headers and include/linux/pci_ids.h with device/vendor specific ones? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
