Re: /usr/include/*/acpi.h

Re: /usr/include/*/acpi.h

[Robert Hancock]

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 hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: /usr/include/*/acpi.h

[Len Brown]

> >>> 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

Re: /usr/include/*/acpi.h

[Petr Baudis]

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