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
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.