Re: [PATCH/resend/bypass] um: Preinclude include/linux/kern_levels.h

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Sep 25, 2012 at 12:20:55PM -0700, Linus Torvalds wrote:
> IOW, this part of the patch:
> 
> -       c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include user.h
> $(CFLAGS_$(basetarget).o)
> +       c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include
> $(srctree)/include/linux/kern_levels.h -include user.h
> $(CFLAGS_$(basetarget).o)
> 
> just makes me go want to puke. The user.h file already has other
> #include's in it, so I really don't see why you create this insane
> special case.
> 
> And why does UM have those "UM_KERN_XYZ" defines in the first place?
> Why isn't it just using KERN_XYZ directly? Is it because kern_levels.h
> didn't use to exist, so it was some kind of "let's create our own that
> we can hide in our special headers".

Because user.h is included *without* kernel headers in include path.
It's for the stuff that is compiled with host libc headers.  Keep in
mind that UML talks to libc like normal architecture would talk to
hardware.  IOW, analogs of asm glue are in (host) userland C.  And
they need libc headers instead of the kernel ones.  That's what that
USER_OBJ thing is about.  Kernel-side constants, etc. are delivered
to that sucker using the same mechanism we normally use to give them
to assembler - asm-offsets.c.  And here, of course, slapping ifndef
__ASSEMBLER__ around the tricky bits will not work - the header itself
is just fine, but getting kernel headers in the search path really
isn't.

	I agree that proposed solution is ugly.  What we can do is copy
the damn header into include/generated and #include <generated/kern_levels.h>
from user.h.  And kill UM_KERN_... stuff.  Objections?