Assigning to the reviewer of  CL: https://codereview.chromium.org/2522843002/ for further updates.

As mentioned above, "GamepadService has another customer PepperGamepadHost which still use the IPC messages,not mojo", it is the reason why we cannot replace base::SharedMemory by mojo::SharedBuffer in GamepadService. While in render process side, in GamepadSharedMemoryReader, we can replace it first to avoid the "unwrap".

I'll start to implement the "base::SharedMemory" to "mojo::SharedBuffer" replacement in GamepadSharedMemoryReader in next CL soon.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2ae3356d5aea96c53704adabd1804336c176571b

commit 2ae3356d5aea96c53704adabd1804336c176571b
Author: ke.he <ke.he@intel.com>
Date: Tue Dec 13 03:44:43 2016

Using mojo::ScopedSharedBufferHandle directly in GamepadSharedMemoryReader

After gamepad mojoification, In renderer side, GamepadSharedMemoryReader has to
"unwrap" the received mojo::ScopedSharedBufferHandle into a
base::SharedMemoryHandle. It is not good.

In this patch we let GamepadSharedMemoryReader completely use mojo::SharedBuffer
to avoid the "unwrap" operation.

BUG =  670655 

Review-Url: https://codereview.chromium.org/2567713003
Cr-Commit-Position: refs/heads/master@{#438039}

[modify] https://crrev.com/2ae3356d5aea96c53704adabd1804336c176571b/content/renderer/gamepad_shared_memory_reader.cc
[modify] https://crrev.com/2ae3356d5aea96c53704adabd1804336c176571b/content/renderer/gamepad_shared_memory_reader.h

It turns out in current stage, we cannot totally replace the base::SharedMemory by Mojo::SharedBufferHandle in GamepadSharedBuffer.

I tried re-implement the GamepadSharedBuffer by mojo::SharedBufferHandle. But found failed to unwrap it into base::SharedMemoryHandle which is needed by PepperGamepadHost. The call stack is:
[155213:155213:1213/152030.145817:357961147339:FATAL:platform_shared_buffer.cc(173)] Check failed: HasOneRef().
    0 0x7f29bf35a37e base::debug::StackTrace::StackTrace()
    1 0x7f29bf37ecbb logging::LogMessage::~LogMessage()
    2 0x7f29bfc89dbb mojo::edk::PlatformSharedBuffer::PassPlatformHandle()
    3 0x7f29bfc609b7 mojo::edk::Core::UnwrapPlatformSharedBufferHandle()
    4 0x7f29bfef881c mojo::UnwrapSharedMemoryHandle()

The "Check failed: HasOneRef()" indicates that you must close the original mojo::sharedbufferHandle if wants to create a new base::SharedMemoryHandle.

So, let's postpone the work of "re-implementing GamepadSharedBuffer by mojo::SharedBufferHandle" till PepperRenderHost are mojoified. 

Sounds good! Want to create a bug for doing that conversion and then block this bug on that one? You can CC jam@ and rockot@ on that bug as well.

OK, I'll create a bug :)

I think this issue can be obsoleted by  issue 865102 .

base::ReadOnlySharedMemoryRegion is the new recommended API for the shared memory and GamepadSharedBufferImpl has been already converted it.

Ke He, do you know if the change in  crbug.com/865102  makes this bug obsolete? I couldn't definitively figure it out, but my hunch is that we would likely still want to use Mojo::SharedBufferHandle directly in GamepadSharedBuffer?

Colin, I think this bug is obsolete. 
In gamepad.mojom the interface is declared as: 
GamepadStartPolling() => (mojo_base.mojom.ReadOnlySharedMemoryRegionmemory_region);

In render process(See https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/gamepad/gamepad_shared_memory_reader.cc?rcl=79c0497461d504bc6594d817a9da24a3afcfdbec&l=24), there is no wrap and unwrap on the base::SharedMemoryHandle anymore. So it is quite clean now.

Thanks, Alex and Ke He!