[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090716200012.GB5994@merkur.ravnborg.org>
Date: Thu, 16 Jul 2009 22:00:12 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Masami Hiramatsu <mhiramat@...hat.com>
Cc: Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
lkml <linux-kernel@...r.kernel.org>,
systemtap <systemtap@...rces.redhat.com>,
kvm <kvm@...r.kernel.org>,
DLE <dle-develop@...ts.sourceforge.net>,
Jim Keniston <jkenisto@...ibm.com>,
"H. Peter Anvin" <hpa@...or.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Vegard Nossum <vegard.nossum@...il.com>,
Avi Kivity <avi@...hat.com>,
Przemys??awPawe??czyk <przemyslaw@...elczyk.it>
Subject: Re: [PATCH -tip -v12 01/11] x86: instruction decoder API
On Thu, Jul 16, 2009 at 01:28:54PM -0400, Masami Hiramatsu wrote:
> Sam Ravnborg wrote:
> >> diff --git a/arch/x86/include/asm/inat.h b/arch/x86/include/asm/inat.h
> >> new file mode 100644
> >> index 0000000..01e079a
> >> --- /dev/null
> >> +++ b/arch/x86/include/asm/inat.h
> >> @@ -0,0 +1,125 @@
> >> +#ifndef _ASM_INAT_INAT_H
> >> +#define _ASM_INAT_INAT_H
> >
> > [With reference to comment on patch 2/12...]
> > You create inat.h here.
> > Could you investigave what is needed to factor out the stuff
> > needed from userspace so we can avoid the ugly havk where
> > you redefine types.h?
>
> Sorry, I'm a bit confusing.
> Would you mean that I should break down user_include.h and
> add those redefined types in inat.h?
No - try to factor out what is needed for your program
so you can avoid user_include.h entirely.
>
> > Maybe create a inat_types.h + inat.h as we do in other cases?
>
> And inat_types.h has two parts, one for kernel, and one for
> userspace(which is moved from user_include.h), is that right?
More like inat_types.h include pure definitions and inat.h
define all the macros (that would be much nicer if expressed
as static inlines).
The real thing to consider is what is needed from your userspace
program and is also required by the kernel.
I did not event remotely try to find out - as I guess you know it.
So try to isolate these bits somehow and you have then nicely dropped
a lot of dependencies on the remainign headers and can thus
hopefully get rid of the ugly usser_include.h hack.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists