LKML Archive on
help / color / mirror / Atom feed
From: Len Brown <>
To: Alexey Starikovskiy <>
Cc: Thorsten Kukuk <>, Thomas Renninger <>,,,
	Linux Kernel Mailing List <>
Subject: Re: /usr/include/*/acpi.h
Date: Thu, 4 Jan 2007 10:15:45 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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


       reply	other threads:[~2007-01-04 15:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2007-01-04 15:15     ` Len Brown [this message]
2007-01-04 15:48       ` /usr/include/*/acpi.h Petr Baudis
     [not found] <fa.qisIxqOea5Rsp26DInWsJ/>
     [not found] ` <fa.5repfGqmg59Vyd5d2/q/>
     [not found]   ` <fa.hncOoCGnx5UaIfEWQxbz2N/>
     [not found]     ` <>
     [not found]       ` <>
2007-01-04 23:36         ` /usr/include/*/acpi.h Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: /usr/include/*/acpi.h' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).