On 18.12.2012, at 03:07, Bhushan Bharat-R65777 <r65...@freescale.com> wrote:
> > >> -----Original Message----- >> From: Alexander Graf [mailto:ag...@suse.de] >> Sent: Tuesday, December 18, 2012 7:00 AM >> To: Bhushan Bharat-R65777 >> Cc: qemu-devel qemu-devel; Peter Maydell; Jan Kiszka; qemu-...@nongnu.org >> List; >> Marcelo Tosatti; David Howells >> Subject: Re: [PATCH v2] Added uapi directory into linux-header >> >> >> On 18.12.2012, at 02:27, Bhushan Bharat-R65777 wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Alexander Graf [mailto:ag...@suse.de] >>>> Sent: Tuesday, December 18, 2012 6:51 AM >>>> To: Bhushan Bharat-R65777 >>>> Cc: qemu-devel qemu-devel; Peter Maydell; Jan Kiszka; >>>> qemu-...@nongnu.org List; Marcelo Tosatti; David Howells >>>> Subject: Re: [PATCH v2] Added uapi directory into linux-header >>>> >>>> >>>> On 18.12.2012, at 02:14, Bhushan Bharat-R65777 wrote: >>>> >>>>>>> +++ b/scripts/update-linux-headers.sh >>>>>>> @@ -46,14 +46,26 @@ for arch in $ARCHLIST; do >>>>>>> >>>>>>> make -C "$linux" INSTALL_HDR_PATH="$tmpdir" SRCARCH=$arch >>>>>>> headers_install >>>>>>> >>>>>>> + if [ -e "$linux/arch/$arch/include/uapi" ] && >>>>>>> + ! [ -e "$output/linux-headers/uapi" ] ; then >>>>>>> + mkdir "$output/linux-headers/uapi" >>>>>> >>>>>> mkdir -p >>>>>> >>>>>> But looking through this whole thing, it seems like the root cause >>>>>> is actually different. We don't want any uapi directories exposed >>>>>> to user space. So let's go back a step: >>>>>> >>>>>> Why do we need the uapi include dir? Because some header is using it. >>>>>> >>>>>> linux-headers/asm-powerpc/kvm_para.h: >>>>> >>>>> The kvm_para.h (also kvm.h) are now defined in include/uapi/asm/ >>>>> >>>>> Is not this the correct thing that any header file in >>>>> include/uapi/asm/ (in >>>> this case kvm_para.h) includes another header file (epapr_hcalls.h) >>>> in same directory? >>>>> >>>>> Also I think now only the uapi/asm/*.h files should be exposed to >>>>> userspace >>>> (QEMU here). >>>> >>>> make headers_install should basically remove all the uapi magic and >>>> give us normal backwards-compatible asm trees :). >>> >>> I am perfectly fine, How we can do this now :) >> >> Well, for starters, do the headers work if you apply the patch I sent in a >> previous mail plus the epapr_hcall.h copy? If so, then that's the way to go >> :) > > Are you really sure that applying a patch and then syncing (or other way > round) is the way you want to go ? Yes, because I'm quite confident we're generating broken headers right now. Alex > > To me it does not look good, I think we can go with the script changes to > make install_header is updated to do the work. > > -Bharat > >> >> >> Alex >> > >
