lkml.org 
[lkml]   [2019]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 00/15] acrn: add the ACRN driver module
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

\
 
 \ /
  Last update: 2019-08-19 07:26    [W:0.148 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site