All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: "Metzger, Markus T" <markus.t.metzger@intel.com>,
	"mingo@elte.hu" <mingo@elte.hu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"harvey.harrison@gmail.com" <harvey.harrison@gmail.com>,
	"sam@ravnborg.org" <sam@ravnborg.org>,
	"jaswinderrajput@gmail.com" <jaswinderrajput@gmail.com>
Subject: Re: [patch 3/5] x86: headers cleanup - ptrace-abi.h
Date: Thu, 15 Jan 2009 09:55:23 -0800	[thread overview]
Message-ID: <496F788B.3090104@zytor.com> (raw)
In-Reply-To: <20090115173324.GC9032@localhost>

Cyrill Gorcunov wrote:
> 
> Let me explain more detailed what I've meant with my prev message.
> Markus said that ptrace_bts_config is supposed to be visible in userspace,
> right? So I've a program which is built under kernel with
> CONFIG_X86_PTRACE_BTS turned on. Then I rebuild my kernel with
> CONFIG_X86_PTRACE_BTS turned off. Then I decide to recompile
> my program for some reason _and_ compilation shouldn't fail
> because of lack of ptrace_bts_config struct. So for userspace
> kernel configuration does matter if it touches data being referenced
> from user-side. BUT all I said is valid (at least I hop so) if _only_
> ptrace_bts_config is supposed to be visible to user-space programs.
> 

CONFIG_* is not visible to userspace.  Furthermore, there is (almost) no
point in putting a structure definition under #ifdef unless it uses data
types that somehow depend on the configuration (and those data
structures would be fundamentally ineligible to be exported to
userspace!!) -- if the feature isn't configured the structure definition
just doesn't get used.

> | 
> | This would be yet another good reason why having them be always defined
> | and 0/1 instead would be such an improvement, but we're not there.
> | 
> 
> oh, that reminds me autoconf horror :) I don't know if it possible
> but we could have some common/base file with all CONFIG_ set to 0/1
> which any header being exported to userspace should include, or
> we could modify unifdef to process headers in fashion: scan the header,
> insert CONFIG_'s refered in the header with value 0/1 at top of the
> header. Not sure if it worth it (too many files are to be touched).
> 

No, no, no, no, no.

We're not exporting CONFIG_* to userspace.

The point was that if we were using #if instead of #ifdef, then -Wundef
could be used to complain instead of silently ignoring sections.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2009-01-15 17:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090114203745.285473388@gmail.com>
2009-01-14 20:37 ` [patch 1/5] x86: headers cleanup - boot.h Cyrill Gorcunov
2009-01-14 21:04   ` Harvey Harrison
2009-01-14 21:11     ` Cyrill Gorcunov
2009-01-14 21:20       ` Cyrill Gorcunov
2009-01-14 20:37 ` [patch 2/5] x86: headers cleanup - prctl.h Cyrill Gorcunov
2009-01-14 20:37 ` [patch 3/5] x86: headers cleanup - ptrace-abi.h Cyrill Gorcunov
2009-01-14 22:21   ` H. Peter Anvin
2009-01-15  8:06     ` Metzger, Markus T
2009-01-15  8:41       ` Cyrill Gorcunov
2009-01-15 16:52         ` H. Peter Anvin
2009-01-15 17:33           ` Cyrill Gorcunov
2009-01-15 17:55             ` H. Peter Anvin [this message]
2009-01-15 18:32               ` Cyrill Gorcunov
2009-01-14 20:37 ` [patch 4/5] x86: headers cleanup - sigcontext32.h Cyrill Gorcunov
2009-01-14 20:37 ` [patch 5/5] x86: headers cleanup - setup.h Cyrill Gorcunov

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=496F788B.3090104@zytor.com \
    --to=hpa@zytor.com \
    --cc=gorcunov@gmail.com \
    --cc=harvey.harrison@gmail.com \
    --cc=jaswinderrajput@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@intel.com \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.org \
    /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.