Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 30 Jan 2019 15:44:14 +0100
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Roman Kiryanov <rkir@google.com>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] drivers: platform: goldfish:
 goldfish_address_space: add a driver
Message-ID: <20190130144414.GA8357@kroah.com>
References: <20190109021112.5836-1-rkir@google.com>
 <20190109021112.5836-2-rkir@google.com>
 <20190122110712.GA1004@kroah.com>
 <CAOGAQeo1Kv55EUn2sYPOt9EgBMfN=+o_A4KOPVgqbJHo+HN-Sw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOGAQeo1Kv55EUn2sYPOt9EgBMfN=+o_A4KOPVgqbJHo+HN-Sw@mail.gmail.com>
User-Agent: Mutt/1.11.2 (2019-01-07)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jan 29, 2019 at 12:32:12AM -0800, Roman Kiryanov wrote:
> > How does QEMU do this today?  There isn't a virtio or some other virtual
> > memory device that allows memory regions to be shared?  I can't believe
> > that there isn't one yet.  If not, then this should be some kind of
> > "generic" QEMU memory device, not a "goldfish" specific one, right?
> 
> I also thought this should not be something unique to us. So I asked
> in our internal mailing list, I heard nothing back.
> 
> > Please work with the QEMU developers on this, I need their ack before I
> > can take something like this.
> 
> This is a good point. I asked there (nothing since 1/24):
> 
> http://lists.nongnu.org/archive/html/qemu-discuss/2019-01/msg00055.html
> 
> When we were working on our device side, we had to change some QEMU
> code and later noticed that HAXM also requires some fixes (we had
> meetings with Intel). I suppose QEMU does not have this feature yet.
> 
> Could you please tell if we can proceed with upstreaming as is?

Also, why does the other Android "emulator", cuttlefish, not need
special drivers like this and the other goldfish drivers?  Shouldn't you
be using the same interfaces that they use that are already merged
upstream?

Actually, now that cuttlefish works on a mainline kernel, can't we just
delete the existing goldfish code?

thanks,

greg k-h