On Mon, Aug 19, 2019 at 10:39:32AM +0800, Zhao, Yakui wrote: > > > On 2019年08月16日 15:03, Greg KH wrote: > > On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote: > > > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > > > > The first three patches are the changes under x86/acrn, which adds the > > > > required APIs for the driver and reports the X2APIC caps. > > > > The remaining patches add the ACRN driver module, which accepts the > > > > ioctl > > > > from user-space and then communicate with the low-level ACRN hypervisor > > > > by using hypercall. > > > > > > I have a problem with that: you're adding interfaces to arch/x86/ and > > > its users go into staging. Why? Why not directly put the driver where > > > it belongs, clean it up properly and submit it like everything else is > > > submitted? > > > > > > I don't want to have stuff in arch/x86/ which is used solely by code in > > > staging and the latter is lingering there indefinitely because no one is > > > cleaning it up... > > > > I agree, stuff in drivers/staging/ must be self-contained, with no > > changes outside of the code's subdirectory needed in order for it to > > work. That way it is trivial for us to delete it when it never gets > > cleaned up :) > > Thanks for pointing out the rule of drivers/staging. > The acrn staging driver is one self-contained driver. But it has some > dependency on arch/x86/acrn and need to call the APIs in arch/x86/acrn.
Then it should not be in drivers/staging/ Please work to get this accepted "normally". thanks, greg k-h _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
