Re: [RFC] [PATCH] Split host arch headers for UML's benefit

[Jeff Dike <jdike@addtoit.com>]

On Tue, Aug 16, 2005 at 10:46:56AM -0700, Zachary Amsden wrote:
> I like this approach.  In general, it seems beneficial to split these 
> into ABI and kernel implementation.  Also, this stuff eventually works 
> its way into userspace headers.  It is not really clear which asm-xxx 
> kernel headers are valid to include in userspace.  There are definitely 
> multiple classes of things in the kernel header files : ABI definitions, 
> user-useful macros and inlines, and things that are privately useful the 
> kernel.  The ptrace split seems quite well defined here; the system 
> split is a little less obvious, but I don't object to the way you have 
> done it.

Yeah, the ptrace split is nice and ABI-like - the system split is more
of a mess.

> I've always wondered why we didn't have memory barriers in either 
> asm/atomic.h or asm/barrier.h; system.h seems to just have a mixed bag 
> of goodies.

That may make sense.

> Two things about the system.h split - do you use
> arch_align_stack()?.  

Something does, UML doesn't build without one.


> Also, do you use the alternative instruction replacement functionality, 
> or do you just need the macro?  If you don't actually implement 
> instruction replacement, it seems you could more easily redefine these to be
> 
> #define alternative(oldinstr, newinstr, feature) \
>    asm volatile(oldinstr) ::: "memory")

Possibly, I don't knowingly use it, but given my borrowing of host
arch headers, and most asm works just as well in UML as on the host,
there could be some use in UML.

				Jeff