linux-kernel - Re: [PATCH v3 2/3] drivers: platform: goldfish: goldfish_address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190130144414.GA8357@kroah.com>
Date:   Wed, 30 Jan 2019 15:44:14 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Roman Kiryanov <rkir@...gle.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] drivers: platform: goldfish:
 goldfish_address_space: add a driver

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