From: Greg KH <gregkh@linuxfoundation.org>
To: "Zhao, Yakui" <yakui.zhao@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
devel@driverdev.osuosl.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
Date: Mon, 19 Aug 2019 07:25:05 +0200 [thread overview]
Message-ID: <20190819052505.GA915@kroah.com> (raw)
In-Reply-To: <78897bb2-e6eb-cac2-7166-eccb7cd5c959@intel.com>
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote:
>
>
> On 2019年08月16日 14:39, 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?
>
> Thanks for your reply and the concern.
>
> After taking a look at several driver examples(gma500, android), it seems
> that they are firstly added into drivers/staging/XXX and then moved to
> drivers/XXX after the driver becomes mature.
> So we refer to this method to upstream ACRN driver part.
Those two examples are probably the worst examples to ever look at :)
The code quality of those submissions was horrible, gma500 took a very
long time to clean up and there are parts of the android code that are
still in staging to this day.
> If the new driver can also be added by skipping the staging approach,
> we will refine it and then submit it in normal process.
That is the normal process, staging should not be needed at all for any
code. It is a fall-back for when the company involved has no idea of
how to upstream their code, which should NOT be the case here.
thanks,
greg k-h
next prev parent reply other threads:[~2019-08-19 5:25 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 2:25 [RFC PATCH 00/15] acrn: add the ACRN driver module Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 01/15] x86/acrn: Report X2APIC for ACRN guest Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 02/15] x86/acrn: Add two APIs to add/remove driver-specific upcall ISR handler Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 03/15] x86/acrn: Add hypercall for ACRN guest Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 04/15] drivers/acrn: add the basic framework of acrn char device driver Zhao Yakui
2019-08-16 7:05 ` Greg KH
2019-08-19 4:02 ` Zhao, Yakui
2019-08-19 5:26 ` Greg KH
2019-08-16 11:28 ` Dan Carpenter
2019-08-16 2:25 ` [RFC PATCH 05/15] drivers/acrn: add driver-specific hypercall for ACRN_HSM Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 06/15] drivers/acrn: add the support of querying ACRN api version Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 07/15] drivers/acrn: add acrn vm/vcpu management for ACRN_HSM char device Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 08/15] drivers/acrn: add VM memory management for ACRN " Zhao Yakui
2019-08-16 12:58 ` Dan Carpenter
2019-08-19 5:32 ` Zhao, Yakui
2019-08-19 7:39 ` Dan Carpenter
2019-08-19 7:46 ` Borislav Petkov
2019-08-20 2:25 ` Zhao, Yakui
2019-08-16 2:25 ` [RFC PATCH 09/15] drivers/acrn: add passthrough device support Zhao Yakui
2019-08-16 13:05 ` Dan Carpenter
2019-08-16 2:25 ` [RFC PATCH 10/15] drivers/acrn: add interrupt injection support Zhao Yakui
2019-08-16 13:12 ` Dan Carpenter
2019-08-19 4:59 ` Zhao, Yakui
2019-08-16 2:25 ` [RFC PATCH 11/15] drivers/acrn: add the support of handling emulated ioreq Zhao Yakui
2019-08-16 13:39 ` Dan Carpenter
2019-08-19 4:54 ` Zhao, Yakui
2019-08-16 2:25 ` [RFC PATCH 12/15] drivers/acrn: add driver-specific IRQ handle to dispatch IO_REQ request Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 13/15] drivers/acrn: add service to obtain Power data transition Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 14/15] drivers/acrn: add the support of irqfd and eventfd Zhao Yakui
2019-08-16 2:25 ` [RFC PATCH 15/15] drivers/acrn: add the support of offline SOS cpu Zhao Yakui
2019-08-19 10:34 ` Dan Carpenter
2019-08-20 2:23 ` Zhao, Yakui
2019-08-16 6:39 ` [RFC PATCH 00/15] acrn: add the ACRN driver module Borislav Petkov
2019-08-16 7:03 ` Greg KH
2019-08-19 2:39 ` Zhao, Yakui
2019-08-19 5:25 ` Greg KH
2019-08-19 1:44 ` Zhao, Yakui
2019-08-19 5:25 ` Greg KH [this message]
2019-08-19 5:39 ` Zhao, Yakui
2019-08-19 6:18 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190819052505.GA915@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bp@alien8.de \
--cc=devel@driverdev.osuosl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
--cc=yakui.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.