Re: /usr/include/*/acpi.h
Petr Baudis wrote: On Thu, Jan 04, 2007 at 04:15:45PM CET, Len Brown wrote: This header files are part of the linux kernel, and thus of course available in /usr/include/{asm,linux}. So you pick up all of the kernel include/linux and include/asm*? (but exclude include/acpi/, which is as much a kernel header as the above) Yes, we do not exclude any files from the kernel headers package, since it is safer to have an extra file there than miss something that something in userspace *could* need - or that is not needed now but can silently become useful for something userspace in the future. An "all headers part of the linux kernel" is much safer definition than "a somewhat random selection of kernel headers". I wouldn't agree with this. We have what headers are to be used in userspace now well defined with the "make headers_install" feature in the kernel, which is what Fedora Core 6 is basing its kernel headers on. Including all headers is simply asking for userspace to use functions, etc. from the kernel source which they have no business using. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/include/*/acpi.h
On Thu, Jan 04, 2007 at 04:15:45PM CET, Len Brown wrote: > > > This header files are part of the linux kernel, and thus of course > > > available in /usr/include/{asm,linux}. > > So you pick up all of the kernel include/linux and include/asm*? > (but exclude include/acpi/, which is as much a kernel header as the above) Yes, we do not exclude any files from the kernel headers package, since it is safer to have an extra file there than miss something that something in userspace *could* need - or that is not needed now but can silently become useful for something userspace in the future. An "all headers part of the linux kernel" is much safer definition than "a somewhat random selection of kernel headers". -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The meaning of Stonehenge in Traflamadorian, when viewed from above, is: "Replacement part being rushed with all possible speed." -- Kurt Vonnegut, Sirens from Titan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/include/*/acpi.h
> >>> Why do the following files appear in OpenSuse 10.2? > >>> > >>> $ find /usr/include -name '*acpi*' > >>> /usr/include/asm/acpi.h > >>> /usr/include/asm-x86_64/acpi.h > >>> /usr/include/asm-i386/acpi.h > >>> /usr/include/linux/acpi.h > >>> /usr/include/linux/pci-acpi.h > >>> > >>> They are not present on a Fedora Core 6 system. > >>> > >> No idea. I never used them and I don't know any user space tool using > >> them. > >> > >> What is the reason you ask this for, do you get name clashes with other > >> programs, should they get reverted for cleanup reasons? Cleanup reasons. I want to know what the constraints are for who sees what header. Right now we have some issues with all kinds of ACPICA core-internal stuff being exported to the rest of the kernel. Makes sense to think about what is exported to user-space while thinking about it -- and I just happened to notice that OS and FC are different here. > > This header files are part of the linux kernel, and thus of course > > available in /usr/include/{asm,linux}. So you pick up all of the kernel include/linux and include/asm*? (but exclude include/acpi/, which is as much a kernel header as the above) What in user-space looks at linux/*.h and what kind of stuff should we be exporting there -- or not exporting there? linux/acpi.h has its entire contents inside #ifdef CONFIG_ACPI and Fedora Core ships without it -- so it seems a pretty safe bet that if anything in user-space is using it, then it must be pretty obscure. ACPI is, after-all, a kernel/BIOS interface -- and to the extent that we expose it to user-space we have certainly failed to abstract it. I don't see any harm in user-space seeing linux/acpi.h, but I also see no benefit. We could delete it, but we could not delete the asm/acpi.h files which are equally useless to user-space. I'm thinking that we should move the core internal stuff (most of include/acpi/) under drivers/acpi where only the core can see it. (2.4 did it this way, as so lots of drivers in 2.6) Perhaps linux/acpi.h should be the place where non-core parts of the Linux kernel pick up what they need to know to talk to the ACPI sub-system. Unclear what to do about visibility to user-space. I don't see us wanting to export anything, so the goal is to not pollute user-space as cleanly as possible. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/include/*/acpi.h
Why do the following files appear in OpenSuse 10.2? $ find /usr/include -name '*acpi*' /usr/include/asm/acpi.h /usr/include/asm-x86_64/acpi.h /usr/include/asm-i386/acpi.h /usr/include/linux/acpi.h /usr/include/linux/pci-acpi.h They are not present on a Fedora Core 6 system. No idea. I never used them and I don't know any user space tool using them. What is the reason you ask this for, do you get name clashes with other programs, should they get reverted for cleanup reasons? Cleanup reasons. I want to know what the constraints are for who sees what header. Right now we have some issues with all kinds of ACPICA core-internal stuff being exported to the rest of the kernel. Makes sense to think about what is exported to user-space while thinking about it -- and I just happened to notice that OS and FC are different here. This header files are part of the linux kernel, and thus of course available in /usr/include/{asm,linux}. So you pick up all of the kernel include/linux and include/asm*? (but exclude include/acpi/, which is as much a kernel header as the above) What in user-space looks at linux/*.h and what kind of stuff should we be exporting there -- or not exporting there? linux/acpi.h has its entire contents inside #ifdef CONFIG_ACPI and Fedora Core ships without it -- so it seems a pretty safe bet that if anything in user-space is using it, then it must be pretty obscure. ACPI is, after-all, a kernel/BIOS interface -- and to the extent that we expose it to user-space we have certainly failed to abstract it. I don't see any harm in user-space seeing linux/acpi.h, but I also see no benefit. We could delete it, but we could not delete the asm/acpi.h files which are equally useless to user-space. I'm thinking that we should move the core internal stuff (most of include/acpi/) under drivers/acpi where only the core can see it. (2.4 did it this way, as so lots of drivers in 2.6) Perhaps linux/acpi.h should be the place where non-core parts of the Linux kernel pick up what they need to know to talk to the ACPI sub-system. Unclear what to do about visibility to user-space. I don't see us wanting to export anything, so the goal is to not pollute user-space as cleanly as possible. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/include/*/acpi.h
On Thu, Jan 04, 2007 at 04:15:45PM CET, Len Brown wrote: This header files are part of the linux kernel, and thus of course available in /usr/include/{asm,linux}. So you pick up all of the kernel include/linux and include/asm*? (but exclude include/acpi/, which is as much a kernel header as the above) Yes, we do not exclude any files from the kernel headers package, since it is safer to have an extra file there than miss something that something in userspace *could* need - or that is not needed now but can silently become useful for something userspace in the future. An all headers part of the linux kernel is much safer definition than a somewhat random selection of kernel headers. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ The meaning of Stonehenge in Traflamadorian, when viewed from above, is: Replacement part being rushed with all possible speed. -- Kurt Vonnegut, Sirens from Titan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/include/*/acpi.h
Petr Baudis wrote: On Thu, Jan 04, 2007 at 04:15:45PM CET, Len Brown wrote: This header files are part of the linux kernel, and thus of course available in /usr/include/{asm,linux}. So you pick up all of the kernel include/linux and include/asm*? (but exclude include/acpi/, which is as much a kernel header as the above) Yes, we do not exclude any files from the kernel headers package, since it is safer to have an extra file there than miss something that something in userspace *could* need - or that is not needed now but can silently become useful for something userspace in the future. An all headers part of the linux kernel is much safer definition than a somewhat random selection of kernel headers. I wouldn't agree with this. We have what headers are to be used in userspace now well defined with the make headers_install feature in the kernel, which is what Fedora Core 6 is basing its kernel headers on. Including all headers is simply asking for userspace to use functions, etc. from the kernel source which they have no business using. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/