Messages in this thread | | | Date | Tue, 25 Sep 2012 20:43:56 +0100 | From | Al Viro <> | Subject | Re: [PATCH/resend/bypass] um: Preinclude include/linux/kern_levels.h |
| |
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?
| |