Am Tue, 25 Sep 2012 22:37:13 +0200 schrieb Geert Uytterhoeven <ge...@linux-m68k.org>:
> On Tue, Sep 25, 2012 at 9:43 PM, Al Viro <v...@zeniv.linux.org.uk> > wrote: > > 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. > > Indeed. > > > 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? > > My first submission had "We may convert all UM_KERN_* users to KERN_* > and drop the extra defines?" as a suggestion, but so far I haven't > found time to implement that... > > Still, no one came up with a better patch, and this is a regression. Yeah, I'd like to take the "ugly" patch to get rid of the regresion. Later we can get rid of UM_KERN_*, which is IMHO also very ugly. Thanks, //richard ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
