All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Cc: Thorsten Kukuk <kukuk@suse.de>, Thomas Renninger <trenn@suse.de>,
	linux-acpi@vger.kernel.org, pbaudis@suse.cz,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: /usr/include/*/acpi.h
Date: Thu, 4 Jan 2007 10:15:45 -0500	[thread overview]
Message-ID: <200701041015.45525.lenb@kernel.org> (raw)
In-Reply-To: <459CDEB0.5040302@linux.intel.com>

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

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

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-03 20:52 /usr/include/*/acpi.h Len Brown
2007-01-04  8:45 ` /usr/include/*/acpi.h Thomas Renninger
2007-01-04 10:49   ` /usr/include/*/acpi.h Thorsten Kukuk
2007-01-04 11:02     ` /usr/include/*/acpi.h Alexey Starikovskiy
2007-01-04 15:15       ` Len Brown [this message]
2007-01-04 15:48         ` /usr/include/*/acpi.h Petr Baudis
     [not found] <fa.qisIxqOea5Rsp26DInWsJ/rJdnQ@ifi.uio.no>
     [not found] ` <fa.5repfGqmg59Vyd5d2/q/VejxXRQ@ifi.uio.no>
     [not found]   ` <fa.hncOoCGnx5UaIfEWQxbz2N/cObM@ifi.uio.no>
     [not found]     ` <fa.ATh7MHfuzpd38JCq6srljq+wqOk@ifi.uio.no>
     [not found]       ` <fa.idYO1X1bcDlMl56ySVF7wfk6M2w@ifi.uio.no>
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200701041015.45525.lenb@kernel.org \
    --to=lenb@kernel.org \
    --cc=alexey.y.starikovskiy@linux.intel.com \
    --cc=kukuk@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbaudis@suse.cz \
    --cc=trenn@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.