Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, 2015-04-02 at 14:09 +0200, Michael S. Tsirkin wrote: > On Thu, Apr 02, 2015 at 01:23:06AM -0700, Christoph Hellwig wrote: > > The class ids are a hardware defintion, not a kernel API. > > It's part of the API, it's used to decode values in this sysfs file: > /sys/bus/pci/devices//class > VFIO also made this part of it's kernel API. vfio-pci does expose PCI config space, but it also exposes memory mapped and io port mapped regions of the device. Do we consider the memory mapped config space of every device that can be exposed through vfio to be part of the kernel API? I don't think so. PCI config space is obviously more standardized and vfio-pci plays a greater role in intercepting and interacting with standardized portions, but we don't really care where userspace gets their definitions for config space offsets. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Le Thursday 02 April 2015 à 14:05 +0200, Michael S. Tsirkin a écrit : > On Thu, Apr 02, 2015 at 01:15:30PM +0200, Jean Delvare wrote: > > Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit : > > > On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: > > > > Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : > > > > > The class ids are a hardware defintion, not a kernel API. Just use > > > > > the > > > > > definitions from libpci, or copy over the kernel header if you prefer > > > > > it over the libpci definutions. > > > > > > > > I agree with Christoph, such defines would better come from > > > > pciutils-devel, not the kernel. > > > > > > This just leads to code duplication. Projects that don't link with > > > pciutils don't want to depend on it. > > > > Well, they don't have to depend on anything then, they can keep defining > > their own named IDs. > > > > Please realize that 1* code duplication is impossible to avoid > > completely and 2* this hardly qualifies as code duplication in the first > > place (giving symbolic names to constants is not actual programming.) > > If it's not actual programming, why keep arguing about it? Clam down, please. You brought it on the table, not me. I'm only trying to help. > What's the problem with exporting class IDs? Zero maintainance overhead and > makes > life a bit easier to userspace. Anything that belongs to uapi implies maintenance overhead: greater care to what is being added, and impossibility to rename or remove anything. Plus, as explained before, this is conceptually wrong, these values are defined externally and are not a kernel API. You still have not explained how user-space would actually benefit from the change anyway, as previous kernels did not export that file, projects can't rely on it unless they stop supporting all kernels before v4.1. And again, just because exporting this file (or even part of it) looks convenient, doesn't mean it's right. I am under the impression that you did not read my previous explanations very carefully. That's sad because they took me a long time to write. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 01:23:06AM -0700, Christoph Hellwig wrote: > The class ids are a hardware defintion, not a kernel API. It's part of the API, it's used to decode values in this sysfs file: /sys/bus/pci/devices//class VFIO also made this part of it's kernel API. > Just use the > definitions from libpci, or copy over the kernel header if you prefer > it over the libpci definutions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 01:15:30PM +0200, Jean Delvare wrote: > Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit : > > On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: > > > Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : > > > > The class ids are a hardware defintion, not a kernel API. Just use the > > > > definitions from libpci, or copy over the kernel header if you prefer > > > > it over the libpci definutions. > > > > > > I agree with Christoph, such defines would better come from > > > pciutils-devel, not the kernel. > > > > This just leads to code duplication. Projects that don't link with > > pciutils don't want to depend on it. > > Well, they don't have to depend on anything then, they can keep defining > their own named IDs. > > Please realize that 1* code duplication is impossible to avoid > completely and 2* this hardly qualifies as code duplication in the first > place (giving symbolic names to constants is not actual programming.) If it's not actual programming, why keep arguing about it? What's the problem with exporting class IDs? Zero maintainance overhead and makes life a bit easier to userspace. > > -- > Jean Delvare > SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit : > On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: > > Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : > > > The class ids are a hardware defintion, not a kernel API. Just use the > > > definitions from libpci, or copy over the kernel header if you prefer > > > it over the libpci definutions. > > > > I agree with Christoph, such defines would better come from > > pciutils-devel, not the kernel. > > This just leads to code duplication. Projects that don't link with > pciutils don't want to depend on it. Well, they don't have to depend on anything then, they can keep defining their own named IDs. Please realize that 1* code duplication is impossible to avoid completely and 2* this hardly qualifies as code duplication in the first place (giving symbolic names to constants is not actual programming.) -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: > Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : > > The class ids are a hardware defintion, not a kernel API. Just use the > > definitions from libpci, or copy over the kernel header if you prefer > > it over the libpci definutions. > > I agree with Christoph, such defines would better come from > pciutils-devel, not the kernel. This just leads to code duplication. Projects that don't link with pciutils don't want to depend on it. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : > The class ids are a hardware defintion, not a kernel API. Just use the > definitions from libpci, or copy over the kernel header if you prefer > it over the libpci definutions. I agree with Christoph, such defines would better come from pciutils-devel, not the kernel. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 09:44:24AM +0200, Jean Delvare wrote: > It could be that a small subset of pci_ids.h could be shared with > user-space. I'm thinking of classes, because that list is short and > stable, so we can give some stability guarantees. But I don't know if > the user-space projects you quoted actually use that, so even that may > not be worth it. > > -- > Jean Delvare > SUSE L3 Support Yes, class IDs is the part that's duplicated across multiple userspace projects. So exporting it is exactly what v2 of the patch did: mid.gmane.org/1427714755-16873-1-git-send-email-...@redhat.com Please review that. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Hi Michael, Bjorn and all, On Sun, 29 Mar 2015 15:36:55 +0200, Michael S. Tsirkin wrote: > The macros in pci_ids.h are pretty useful for userspace > using the pci sysfs interface, e.g. to decode class > device and vendor sysfs files. > > At the moment userspace is forced to duplicate these macros (e.g. QEMU does > this, so does gpxe, seabios, etc), it is better to export them in > /usr/include/linux/pci_ids.h so everyone can just include this header. > > This patchset is structured as follows: > 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; >a stub file is created in include/linux/pci_ids.h to avoid breaking >bisect > 2. all users are converted to use the new header > 3. include/linux/pci_ids.h is removed > 4. cleanups for several issues detected during step 2 > > The patchset was built on several architectures (mips/ppc/x86), > boot-tested on x86 only - build seems sufficient for this kind of > change. > > I think the pci tree is the most appropriate for this patchset. > Please review it, and consider for 4.1. I've been thinking some more about the whole move and I'm not so sure it is a good idea. I don't think that pci_ids.h qualifies as a stable API for user-space. 1* For one thing, the header of that file says: * Do not add new entries to this file unless the definitions * are shared between multiple drivers. which implies that some IDs will never make it into the file, even if some user-space tool would benefit from it. 2* For another, we have sometimes removed definitions from that file, see commits 7ee4910ab31c4b1fafb7e4f273cbe9340ac953aa, fee8bf4b74e37bfeb8998a349cb788680eb3f634 or 26e8220adb0aec43b7acafa0f1431760eee28522 for recent examples of this. So user-space tools can't assume that an ID being present in that file one day will stay there forever. 3* Also IDs are being added over time, so if you build a recent version of a tool with an old kernel, the most recent IDs may not be there. This all implies that user-space tools will have to keep defining the IDs they use for compatibility anyway. So I don't quite see what good will come from this move. This is a large and intrusive patch set, you would need a significant benefit to justify its cost. I can't see that. I think it would only make (some) sense to declare pci_ids.h a user-space API if we change the rules: all IDs must go in pci_ids.h again, and IDs that go there can no longer be removed. But that's a big change (there was a reason for the current rule) and that doesn't even address point 3 above. So I seriously doubt it's worth it. Just because some user-space tools give symbolic names to PCI IDs isn't a sufficient reason to export the kernel's pci_ids.h to user-space. I mean, defines the ARRAY_SIZE macro, and many many user-space projects have a similar macro because it's very useful. That doesn't mean that the kernel should export it. Same goes for a countless list of utility macros, linked list management etc, most of that is reimplemented in various user-space libraries and utilities but it is certainly not the kernel's responsibility to provide the implementation. Kernel/user-space API should be limited to what is required, not what is possible or what looks convenient. Remember it comes with big constraints, so as a general rule it must stay as small as possible. It could be that a small subset of pci_ids.h could be shared with user-space. I'm thinking of classes, because that list is short and stable, so we can give some stability guarantees. But I don't know if the user-space projects you quoted actually use that, so even that may not be worth it. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. I agree with Christoph, such defines would better come from pciutils-devel, not the kernel. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 09:44:24AM +0200, Jean Delvare wrote: It could be that a small subset of pci_ids.h could be shared with user-space. I'm thinking of classes, because that list is short and stable, so we can give some stability guarantees. But I don't know if the user-space projects you quoted actually use that, so even that may not be worth it. -- Jean Delvare SUSE L3 Support Yes, class IDs is the part that's duplicated across multiple userspace projects. So exporting it is exactly what v2 of the patch did: mid.gmane.org/1427714755-16873-1-git-send-email-...@redhat.com Please review that. -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Hi Michael, Bjorn and all, On Sun, 29 Mar 2015 15:36:55 +0200, Michael S. Tsirkin wrote: The macros in pci_ids.h are pretty useful for userspace using the pci sysfs interface, e.g. to decode class device and vendor sysfs files. At the moment userspace is forced to duplicate these macros (e.g. QEMU does this, so does gpxe, seabios, etc), it is better to export them in /usr/include/linux/pci_ids.h so everyone can just include this header. This patchset is structured as follows: 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; a stub file is created in include/linux/pci_ids.h to avoid breaking bisect 2. all users are converted to use the new header 3. include/linux/pci_ids.h is removed 4. cleanups for several issues detected during step 2 The patchset was built on several architectures (mips/ppc/x86), boot-tested on x86 only - build seems sufficient for this kind of change. I think the pci tree is the most appropriate for this patchset. Please review it, and consider for 4.1. I've been thinking some more about the whole move and I'm not so sure it is a good idea. I don't think that pci_ids.h qualifies as a stable API for user-space. 1* For one thing, the header of that file says: * Do not add new entries to this file unless the definitions * are shared between multiple drivers. which implies that some IDs will never make it into the file, even if some user-space tool would benefit from it. 2* For another, we have sometimes removed definitions from that file, see commits 7ee4910ab31c4b1fafb7e4f273cbe9340ac953aa, fee8bf4b74e37bfeb8998a349cb788680eb3f634 or 26e8220adb0aec43b7acafa0f1431760eee28522 for recent examples of this. So user-space tools can't assume that an ID being present in that file one day will stay there forever. 3* Also IDs are being added over time, so if you build a recent version of a tool with an old kernel, the most recent IDs may not be there. This all implies that user-space tools will have to keep defining the IDs they use for compatibility anyway. So I don't quite see what good will come from this move. This is a large and intrusive patch set, you would need a significant benefit to justify its cost. I can't see that. I think it would only make (some) sense to declare pci_ids.h a user-space API if we change the rules: all IDs must go in pci_ids.h again, and IDs that go there can no longer be removed. But that's a big change (there was a reason for the current rule) and that doesn't even address point 3 above. So I seriously doubt it's worth it. Just because some user-space tools give symbolic names to PCI IDs isn't a sufficient reason to export the kernel's pci_ids.h to user-space. I mean, linux/kernel.h defines the ARRAY_SIZE macro, and many many user-space projects have a similar macro because it's very useful. That doesn't mean that the kernel should export it. Same goes for a countless list of utility macros, linked list management etc, most of that is reimplemented in various user-space libraries and utilities but it is certainly not the kernel's responsibility to provide the implementation. Kernel/user-space API should be limited to what is required, not what is possible or what looks convenient. Remember it comes with big constraints, so as a general rule it must stay as small as possible. It could be that a small subset of pci_ids.h could be shared with user-space. I'm thinking of classes, because that list is short and stable, so we can give some stability guarantees. But I don't know if the user-space projects you quoted actually use that, so even that may not be worth it. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 01:23:06AM -0700, Christoph Hellwig wrote: The class ids are a hardware defintion, not a kernel API. It's part of the API, it's used to decode values in this sysfs file: /sys/bus/pci/devices/address/class VFIO also made this part of it's kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. I agree with Christoph, such defines would better come from pciutils-devel, not the kernel. This just leads to code duplication. Projects that don't link with pciutils don't want to depend on it. -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, Apr 02, 2015 at 01:15:30PM +0200, Jean Delvare wrote: Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit : On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. I agree with Christoph, such defines would better come from pciutils-devel, not the kernel. This just leads to code duplication. Projects that don't link with pciutils don't want to depend on it. Well, they don't have to depend on anything then, they can keep defining their own named IDs. Please realize that 1* code duplication is impossible to avoid completely and 2* this hardly qualifies as code duplication in the first place (giving symbolic names to constants is not actual programming.) If it's not actual programming, why keep arguing about it? What's the problem with exporting class IDs? Zero maintainance overhead and makes life a bit easier to userspace. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit : On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. I agree with Christoph, such defines would better come from pciutils-devel, not the kernel. This just leads to code duplication. Projects that don't link with pciutils don't want to depend on it. Well, they don't have to depend on anything then, they can keep defining their own named IDs. Please realize that 1* code duplication is impossible to avoid completely and 2* this hardly qualifies as code duplication in the first place (giving symbolic names to constants is not actual programming.) -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
Le Thursday 02 April 2015 à 14:05 +0200, Michael S. Tsirkin a écrit : On Thu, Apr 02, 2015 at 01:15:30PM +0200, Jean Delvare wrote: Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit : On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote: Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit : The class ids are a hardware defintion, not a kernel API. Just use the definitions from libpci, or copy over the kernel header if you prefer it over the libpci definutions. I agree with Christoph, such defines would better come from pciutils-devel, not the kernel. This just leads to code duplication. Projects that don't link with pciutils don't want to depend on it. Well, they don't have to depend on anything then, they can keep defining their own named IDs. Please realize that 1* code duplication is impossible to avoid completely and 2* this hardly qualifies as code duplication in the first place (giving symbolic names to constants is not actual programming.) If it's not actual programming, why keep arguing about it? Clam down, please. You brought it on the table, not me. I'm only trying to help. What's the problem with exporting class IDs? Zero maintainance overhead and makes life a bit easier to userspace. Anything that belongs to uapi implies maintenance overhead: greater care to what is being added, and impossibility to rename or remove anything. Plus, as explained before, this is conceptually wrong, these values are defined externally and are not a kernel API. You still have not explained how user-space would actually benefit from the change anyway, as previous kernels did not export that file, projects can't rely on it unless they stop supporting all kernels before v4.1. And again, just because exporting this file (or even part of it) looks convenient, doesn't mean it's right. I am under the impression that you did not read my previous explanations very carefully. That's sad because they took me a long time to write. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Thu, 2015-04-02 at 14:09 +0200, Michael S. Tsirkin wrote: On Thu, Apr 02, 2015 at 01:23:06AM -0700, Christoph Hellwig wrote: The class ids are a hardware defintion, not a kernel API. It's part of the API, it's used to decode values in this sysfs file: /sys/bus/pci/devices/address/class VFIO also made this part of it's kernel API. vfio-pci does expose PCI config space, but it also exposes memory mapped and io port mapped regions of the device. Do we consider the memory mapped config space of every device that can be exposed through vfio to be part of the kernel API? I don't think so. PCI config space is obviously more standardized and vfio-pci plays a greater role in intercepting and interacting with standardized portions, but we don't really care where userspace gets their definitions for config space offsets. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Sun, Mar 29, 2015 at 10:59:45AM -0700, Joe Perches wrote: > On Sun, 2015-03-29 at 15:36 +0200, Michael S. Tsirkin wrote: > > The macros in pci_ids.h are pretty useful for userspace > > using the pci sysfs interface, e.g. to decode class > > device and vendor sysfs files. > > > > At the moment userspace is forced to duplicate these macros (e.g. QEMU does > > this, so does gpxe, seabios, etc), it is better to export them in > > /usr/include/linux/pci_ids.h so everyone can just include this header. > > > > This patchset is structured as follows: > > 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; > >a stub file is created in include/linux/pci_ids.h to avoid breaking > >bisect > > 2. all users are converted to use the new header > > 3. include/linux/pci_ids.h is removed > > 4. cleanups for several issues detected during step 2 > > > > The patchset was built on several architectures (mips/ppc/x86), > > boot-tested on x86 only - build seems sufficient for this kind of > > change. > > > > I think the pci tree is the most appropriate for this patchset. > > Please review it, and consider for 4.1. > > Hello again Michael. > > It's nicer if you send this cover letter to all mailing lists > that receive any of the individual patches so that people can > reply to the 0/n patch and a single discussion thread can > happen for generic issues for the entire patchset. > > It'd be even nicer to cc all of the maintainers of any of the > sections modified, but vger mailing lists reject any email > with more than 2k of email headers. Unfortunately, patchsets > for multiple subsystems create long cc lists that generally > exceed this limit. Exactly. That's also why I had to split the patchset - at least the individual patches are Cc'd fully then. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Sun, Mar 29, 2015 at 10:59:45AM -0700, Joe Perches wrote: On Sun, 2015-03-29 at 15:36 +0200, Michael S. Tsirkin wrote: The macros in pci_ids.h are pretty useful for userspace using the pci sysfs interface, e.g. to decode class device and vendor sysfs files. At the moment userspace is forced to duplicate these macros (e.g. QEMU does this, so does gpxe, seabios, etc), it is better to export them in /usr/include/linux/pci_ids.h so everyone can just include this header. This patchset is structured as follows: 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; a stub file is created in include/linux/pci_ids.h to avoid breaking bisect 2. all users are converted to use the new header 3. include/linux/pci_ids.h is removed 4. cleanups for several issues detected during step 2 The patchset was built on several architectures (mips/ppc/x86), boot-tested on x86 only - build seems sufficient for this kind of change. I think the pci tree is the most appropriate for this patchset. Please review it, and consider for 4.1. Hello again Michael. It's nicer if you send this cover letter to all mailing lists that receive any of the individual patches so that people can reply to the 0/n patch and a single discussion thread can happen for generic issues for the entire patchset. It'd be even nicer to cc all of the maintainers of any of the sections modified, but vger mailing lists reject any email with more than 2k of email headers. Unfortunately, patchsets for multiple subsystems create long cc lists that generally exceed this limit. Exactly. That's also why I had to split the patchset - at least the individual patches are Cc'd fully then. -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Mar 29 Michael S. Tsirkin wrote: > The macros in pci_ids.h are pretty useful for userspace > using the pci sysfs interface, e.g. to decode class > device and vendor sysfs files. > > At the moment userspace is forced to duplicate these macros (e.g. QEMU does > this, so does gpxe, seabios, etc), it is better to export them in > /usr/include/linux/pci_ids.h so everyone can just include this header. > > This patchset is structured as follows: > 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; >a stub file is created in include/linux/pci_ids.h to avoid breaking >bisect Since linux' include/linux/pci_ids.h is incomplete, I am doubtful that it is appropriate for userspace. > 2. all users are converted to use the new header This step should not be necessary. It has not been done with other headers which were moved to include/uapi. > 3. include/linux/pci_ids.h is removed > 4. cleanups for several issues detected during step 2 -- Stefan Richter -=-= --== - http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Sun, 2015-03-29 at 15:36 +0200, Michael S. Tsirkin wrote: > The macros in pci_ids.h are pretty useful for userspace > using the pci sysfs interface, e.g. to decode class > device and vendor sysfs files. > > At the moment userspace is forced to duplicate these macros (e.g. QEMU does > this, so does gpxe, seabios, etc), it is better to export them in > /usr/include/linux/pci_ids.h so everyone can just include this header. > > This patchset is structured as follows: > 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; >a stub file is created in include/linux/pci_ids.h to avoid breaking >bisect > 2. all users are converted to use the new header > 3. include/linux/pci_ids.h is removed > 4. cleanups for several issues detected during step 2 > > The patchset was built on several architectures (mips/ppc/x86), > boot-tested on x86 only - build seems sufficient for this kind of > change. > > I think the pci tree is the most appropriate for this patchset. > Please review it, and consider for 4.1. Hello again Michael. It's nicer if you send this cover letter to all mailing lists that receive any of the individual patches so that people can reply to the 0/n patch and a single discussion thread can happen for generic issues for the entire patchset. It'd be even nicer to cc all of the maintainers of any of the sections modified, but vger mailing lists reject any email with more than 2k of email headers. Unfortunately, patchsets for multiple subsystems create long cc lists that generally exceed this limit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/86] pci: export pci_ids.h and related cleanups
The macros in pci_ids.h are pretty useful for userspace using the pci sysfs interface, e.g. to decode class device and vendor sysfs files. At the moment userspace is forced to duplicate these macros (e.g. QEMU does this, so does gpxe, seabios, etc), it is better to export them in /usr/include/linux/pci_ids.h so everyone can just include this header. This patchset is structured as follows: 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; a stub file is created in include/linux/pci_ids.h to avoid breaking bisect 2. all users are converted to use the new header 3. include/linux/pci_ids.h is removed 4. cleanups for several issues detected during step 2 The patchset was built on several architectures (mips/ppc/x86), boot-tested on x86 only - build seems sufficient for this kind of change. I think the pci tree is the most appropriate for this patchset. Please review it, and consider for 4.1. Michael S. Tsirkin (86): pci: export pci_ids.h i2c/i801: linux/pci_ids.h -> uapi/linux/pci_ids.h mips/netlogic: use uapi/linux/pci_ids.h directly powerpc/pci: use uapi/linux/pci_ids.h directly x86/gart: use uapi/linux/pci_ids.h directly x86/microcode/amd: use uapi/linux/pci_ids.h directly x86/quirks: use uapi/linux/pci_ids.h directly x86/printk: use uapi/linux/pci_ids.h directly x86/calgary: use uapi/linux/pci_ids.h directly x86/apic/vsmp: use uapi/linux/pci_ids.h directly x86/mm/numa: use uapi/linux/pci_ids.h directly x86/pci/sta2x11: use uapi/linux/pci_ids.h directly acpi/video: use uapi/linux/pci_ids.h directly crypto/ccp: use uapi/linux/pci_ids.h directly crypto/geode: use uapi/linux/pci_ids.h directly dmaengine: use uapi/linux/pci_ids.h directly dma/ioat: use uapi/linux/pci_ids.h directly edac/amd: use uapi/linux/pci_ids.h directly edac/e7xxx: use uapi/linux/pci_ids.h directly edac/e752x: use uapi/linux/pci_ids.h directly edac/i3000: use uapi/linux/pci_ids.h directly edac/i3200: use uapi/linux/pci_ids.h directly edac/i5000: use uapi/linux/pci_ids.h directly edac/i5100: use uapi/linux/pci_ids.h directly edac/i5400: use uapi/linux/pci_ids.h directly edac/i7300: use uapi/linux/pci_ids.h directly edac/i7core: use uapi/linux/pci_ids.h directly edac/i82443bxgx: use uapi/linux/pci_ids.h directly edac/i82860: use uapi/linux/pci_ids.h directly edac/i82875p: use uapi/linux/pci_ids.h directly edac/i82975x: use uapi/linux/pci_ids.h directly edac/ie31200: use uapi/linux/pci_ids.h directly edac/pasemi: use uapi/linux/pci_ids.h directly edac/r82600: use uapi/linux/pci_ids.h directly edac/sbridge: use uapi/linux/pci_ids.h directly edac/x38_edac: use uapi/linux/pci_ids.h directly firewire/ohci: use uapi/linux/pci_ids.h directly gpio/sch: use uapi/linux/pci_ids.h directly i2c/i801: use uapi/linux/pci_ids.h directly ide/generic: use uapi/linux/pci_ids.h directly input/keyboard: use uapi/linux/pci_ids.h directly input/serio: use uapi/linux/pci_ids.h directly macintosh: use uapi/linux/pci_ids.h directly media/ddbridge: use uapi/linux/pci_ids.h directly media/ngene: use uapi/linux/pci_ids.h directly media/fintek: use uapi/linux/pci_ids.h directly media/ite: use uapi/linux/pci_ids.h directly media/nuvoton: use uapi/linux/pci_ids.h directly media/winbond: use uapi/linux/pci_ids.h directly memstick/r592: use uapi/linux/pci_ids.h directly cxl: use uapi/linux/pci_ids.h directly mtd/maps: use uapi/linux/pci_ids.h directly mtd/nand: use uapi/linux/pci_ids.h directly atheros/atlx: use uapi/linux/pci_ids.h directly chelsio/cxgb: use uapi/linux/pci_ids.h directly intel/ixgb: use uapi/linux/pci_ids.h directly brcm80211: use uapi/linux/pci_ids.h directly pci-label: use uapi/linux/pci_ids.h directly x86/thinkpad_acpi: use uapi/linux/pci_ids.h directly scsi/arcmsr: use uapi/linux/pci_ids.h directly scsi/qla1280: use uapi/linux/pci_ids.h directly staging/comedi: use uapi/linux/pci_ids.h directly staging/olpc: use uapi/linux/pci_ids.h directly tty/serial: comment update usb/dwc3: comment update usb/early: use uapi/linux/pci_ids.h directly usb/gadget: use uapi/linux/pci_ids.h directly usb/host: use uapi/linux/pci_ids.h directly usb/misc: use uapi/linux/pci_ids.h directly fbdev/gxt4500: use uapi/linux/pci_ids.h directly fbdev/i740fb: use uapi/linux/pci_ids.h directly fbdev/i810: use uapi/linux/pci_ids.h directly fbdev/riva: use uapi/linux/pci_ids.h directly w1: use uapi/linux/pci_ids.h directly watchdog: use uapi/linux/pci_ids.h directly sound/pci: use uapi/linux/pci_ids.h directly linux/pci: use uapi/linux/pci_ids.h directly linux/pci: drop include/linux/pci_ids.h x86/microcode/amd: drop pci_ids dependency crypto/ccp: drop linux/pci dependencies input/serio: drop pci_ids dependency media/fintek: drop pci_ids dependency brcm80211: drop pci dependency brcm80211: drop pci_ids include staging/olpc: drop pci dependencies usb/dwc3: move ids to pci_ids.h
[PATCH 00/86] pci: export pci_ids.h and related cleanups
The macros in pci_ids.h are pretty useful for userspace using the pci sysfs interface, e.g. to decode class device and vendor sysfs files. At the moment userspace is forced to duplicate these macros (e.g. QEMU does this, so does gpxe, seabios, etc), it is better to export them in /usr/include/linux/pci_ids.h so everyone can just include this header. This patchset is structured as follows: 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; a stub file is created in include/linux/pci_ids.h to avoid breaking bisect 2. all users are converted to use the new header 3. include/linux/pci_ids.h is removed 4. cleanups for several issues detected during step 2 The patchset was built on several architectures (mips/ppc/x86), boot-tested on x86 only - build seems sufficient for this kind of change. I think the pci tree is the most appropriate for this patchset. Please review it, and consider for 4.1. Michael S. Tsirkin (86): pci: export pci_ids.h i2c/i801: linux/pci_ids.h - uapi/linux/pci_ids.h mips/netlogic: use uapi/linux/pci_ids.h directly powerpc/pci: use uapi/linux/pci_ids.h directly x86/gart: use uapi/linux/pci_ids.h directly x86/microcode/amd: use uapi/linux/pci_ids.h directly x86/quirks: use uapi/linux/pci_ids.h directly x86/printk: use uapi/linux/pci_ids.h directly x86/calgary: use uapi/linux/pci_ids.h directly x86/apic/vsmp: use uapi/linux/pci_ids.h directly x86/mm/numa: use uapi/linux/pci_ids.h directly x86/pci/sta2x11: use uapi/linux/pci_ids.h directly acpi/video: use uapi/linux/pci_ids.h directly crypto/ccp: use uapi/linux/pci_ids.h directly crypto/geode: use uapi/linux/pci_ids.h directly dmaengine: use uapi/linux/pci_ids.h directly dma/ioat: use uapi/linux/pci_ids.h directly edac/amd: use uapi/linux/pci_ids.h directly edac/e7xxx: use uapi/linux/pci_ids.h directly edac/e752x: use uapi/linux/pci_ids.h directly edac/i3000: use uapi/linux/pci_ids.h directly edac/i3200: use uapi/linux/pci_ids.h directly edac/i5000: use uapi/linux/pci_ids.h directly edac/i5100: use uapi/linux/pci_ids.h directly edac/i5400: use uapi/linux/pci_ids.h directly edac/i7300: use uapi/linux/pci_ids.h directly edac/i7core: use uapi/linux/pci_ids.h directly edac/i82443bxgx: use uapi/linux/pci_ids.h directly edac/i82860: use uapi/linux/pci_ids.h directly edac/i82875p: use uapi/linux/pci_ids.h directly edac/i82975x: use uapi/linux/pci_ids.h directly edac/ie31200: use uapi/linux/pci_ids.h directly edac/pasemi: use uapi/linux/pci_ids.h directly edac/r82600: use uapi/linux/pci_ids.h directly edac/sbridge: use uapi/linux/pci_ids.h directly edac/x38_edac: use uapi/linux/pci_ids.h directly firewire/ohci: use uapi/linux/pci_ids.h directly gpio/sch: use uapi/linux/pci_ids.h directly i2c/i801: use uapi/linux/pci_ids.h directly ide/generic: use uapi/linux/pci_ids.h directly input/keyboard: use uapi/linux/pci_ids.h directly input/serio: use uapi/linux/pci_ids.h directly macintosh: use uapi/linux/pci_ids.h directly media/ddbridge: use uapi/linux/pci_ids.h directly media/ngene: use uapi/linux/pci_ids.h directly media/fintek: use uapi/linux/pci_ids.h directly media/ite: use uapi/linux/pci_ids.h directly media/nuvoton: use uapi/linux/pci_ids.h directly media/winbond: use uapi/linux/pci_ids.h directly memstick/r592: use uapi/linux/pci_ids.h directly cxl: use uapi/linux/pci_ids.h directly mtd/maps: use uapi/linux/pci_ids.h directly mtd/nand: use uapi/linux/pci_ids.h directly atheros/atlx: use uapi/linux/pci_ids.h directly chelsio/cxgb: use uapi/linux/pci_ids.h directly intel/ixgb: use uapi/linux/pci_ids.h directly brcm80211: use uapi/linux/pci_ids.h directly pci-label: use uapi/linux/pci_ids.h directly x86/thinkpad_acpi: use uapi/linux/pci_ids.h directly scsi/arcmsr: use uapi/linux/pci_ids.h directly scsi/qla1280: use uapi/linux/pci_ids.h directly staging/comedi: use uapi/linux/pci_ids.h directly staging/olpc: use uapi/linux/pci_ids.h directly tty/serial: comment update usb/dwc3: comment update usb/early: use uapi/linux/pci_ids.h directly usb/gadget: use uapi/linux/pci_ids.h directly usb/host: use uapi/linux/pci_ids.h directly usb/misc: use uapi/linux/pci_ids.h directly fbdev/gxt4500: use uapi/linux/pci_ids.h directly fbdev/i740fb: use uapi/linux/pci_ids.h directly fbdev/i810: use uapi/linux/pci_ids.h directly fbdev/riva: use uapi/linux/pci_ids.h directly w1: use uapi/linux/pci_ids.h directly watchdog: use uapi/linux/pci_ids.h directly sound/pci: use uapi/linux/pci_ids.h directly linux/pci: use uapi/linux/pci_ids.h directly linux/pci: drop include/linux/pci_ids.h x86/microcode/amd: drop pci_ids dependency crypto/ccp: drop linux/pci dependencies input/serio: drop pci_ids dependency media/fintek: drop pci_ids dependency brcm80211: drop pci dependency brcm80211: drop pci_ids include staging/olpc: drop pci dependencies usb/dwc3: move ids to pci_ids.h
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Sun, 2015-03-29 at 15:36 +0200, Michael S. Tsirkin wrote: The macros in pci_ids.h are pretty useful for userspace using the pci sysfs interface, e.g. to decode class device and vendor sysfs files. At the moment userspace is forced to duplicate these macros (e.g. QEMU does this, so does gpxe, seabios, etc), it is better to export them in /usr/include/linux/pci_ids.h so everyone can just include this header. This patchset is structured as follows: 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; a stub file is created in include/linux/pci_ids.h to avoid breaking bisect 2. all users are converted to use the new header 3. include/linux/pci_ids.h is removed 4. cleanups for several issues detected during step 2 The patchset was built on several architectures (mips/ppc/x86), boot-tested on x86 only - build seems sufficient for this kind of change. I think the pci tree is the most appropriate for this patchset. Please review it, and consider for 4.1. Hello again Michael. It's nicer if you send this cover letter to all mailing lists that receive any of the individual patches so that people can reply to the 0/n patch and a single discussion thread can happen for generic issues for the entire patchset. It'd be even nicer to cc all of the maintainers of any of the sections modified, but vger mailing lists reject any email with more than 2k of email headers. Unfortunately, patchsets for multiple subsystems create long cc lists that generally exceed this limit. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups
On Mar 29 Michael S. Tsirkin wrote: The macros in pci_ids.h are pretty useful for userspace using the pci sysfs interface, e.g. to decode class device and vendor sysfs files. At the moment userspace is forced to duplicate these macros (e.g. QEMU does this, so does gpxe, seabios, etc), it is better to export them in /usr/include/linux/pci_ids.h so everyone can just include this header. This patchset is structured as follows: 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h; a stub file is created in include/linux/pci_ids.h to avoid breaking bisect Since linux' include/linux/pci_ids.h is incomplete, I am doubtful that it is appropriate for userspace. 2. all users are converted to use the new header This step should not be necessary. It has not been done with other headers which were moved to include/uapi. 3. include/linux/pci_ids.h is removed 4. cleanups for several issues detected during step 2 -- Stefan Richter -=-= --== - http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
