Add a Mojo EDK for Chrome that uses one OS pipe per message pipe.

Add a Mojo EDK for Chrome that uses one OS pipe per message pipe.

TODOs in future cls:
-POSIX
-use shared memory for MessagePipeDispatcher serialization
-work in Windows sandbox (using master.mojom which is implemented but not hooked up in this change)
-XP

BUG=478251
NOPRESUBMIT=true

Committed: https://crrev.com/76bcf0c21e332c08ee7a1601d0c878d1c75541a0
Cr-Commit-Position: refs/heads/master@{#352123}

[jam, 2015-09-17 16:49:35]

jam@chromium.org changed reviewers:
+ yzshen@chromium.org

[Ken Rockot(use gerrit already), 2015-09-23 22:32:15]

rockot@chromium.org changed reviewers:
+ rockot@chromium.org

[Ken Rockot(use gerrit already), 2015-09-23 22:32:18]

Just a few comments which stem from my attempt to build the world locally on
linux with use_chrome_edk=false and building mojo_system_unittests with
use_chrome_edk=true.

One other thing I needed to do, which isn't mentioned inline, is add
"third_party/mojo/src" as the FIRST include_dir in the default_include_dirs
config (//build/config/compiler/BUILD.gn) when use_chrome_edk=false. It seems
kind of hacky, but it should be relatively safe to do and I don't see a good
alternative.

https://codereview.chromium.org/1350023003/diff/280001/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/1350023003/diff/280001/BUILD.gn#newcode764
BUILD.gn:764:
"//third_party/mojo/src/mojo/edk/js/tests:js_to_cpp_bindings_python",
all the python bindings refs should be removed

https://codereview.chromium.org/1350023003/diff/280001/chrome/browser/BUILD.gn
File chrome/browser/BUILD.gn (right):

https://codereview.chromium.org/1350023003/diff/280001/chrome/browser/BUILD.g...
chrome/browser/BUILD.gn:330: if (use_chrome_edk) {
What if we added a few new group targets to //mojo/BUILD.gn to encompass these
conditional deps. I think it'd be nice to isolate usage of use_chrome_edk as
much as possible since we're almost certainly going to remove it some day.

Seems it's used most often for //mojo/edk/system, test runners, and
test_support. We could add a //mojo rule like

group("edk_system") {
  // logic to depend on either //mojo or //third_party based on flag
}

and then just depend on //mojo:edk_system here and everywhere else

Then someday when only the chrome EDK exists, cleanup is a simple find and
replace //mojo:edk_system -> //mojo/edk/system. This would also apply to rules
for run_all_unittests and test_support.


On a related note: several build files which reference use_chrome_edk now are
not importing features.gni and this makes GN sad. Of course that problem goes
away if we consolidate these conditional deps as suggested above.

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/js/test/BUILD.gn
File mojo/edk/js/test/BUILD.gn (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/js/test/BUILD...
mojo/edk/js/test/BUILD.gn:7: test("js_unittests") {
GN seems to not like when there are multiple test targets with the same name,
presumably because this means they have the same output filename.

Maybe we can rename js_unittests and js_integration_tests to have a mojo_ prefix
in the chrome EDK versions? Probably makes sense anyway for the binary names to
include "mojo" in them.

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/BUILD.gn
File mojo/edk/system/BUILD.gn (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/BUILD....
mojo/edk/system/BUILD.gn:137: test("mojo_system_unittests") {
GN also chokes on this, again because of conflicting test target names. In this
case maybe we can just wrap it and all its dependences (basically everything
from line 110 down to EOF) an if (use_chrome_edk), and do the same thing for the
third_party equivalents with if (!use_chrome_edk)

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/data_p...
File mojo/edk/system/data_pipe_producer_dispatcher.cc (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/data_p...
mojo/edk/system/data_pipe_producer_dispatcher.cc:120:
std::min(static_cast<size_t>(num_bytes.Get()),
size_t should be uint32_t

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/data_p...
File mojo/edk/system/data_pipe_unittest.cc (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/data_p...
mojo/edk/system/data_pipe_unittest.cc:28: const MojoHandleSignals kSignalAll =
MOJO_HANDLE_SIGNAL_READABLE |
unused

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/master...
File mojo/edk/system/master_impl_unittest.cc (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/master...
mojo/edk/system/master_impl_unittest.cc:20: static const char kHelloWorld[] =
"hello world";
should move into the OS_WIN block until used on other platforms

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/multip...
File mojo/edk/system/multiprocess_message_pipe_unittest.cc (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/multip...
mojo/edk/system/multiprocess_message_pipe_unittest.cc:324:
MOJO_DUPLICATE_BUFFER_HANDLE_OPTIONS_FLAG_NONE,
I believe you just want nullptr here rather than a flag value

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel_posix.cc (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_posix.cc:8: #include <sys/uio.h>
need sys/stat.h

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_posix.cc:510: stat stat1, stat2;
need struct tag for stat type here

[yzshen1, 2015-09-23 22:47:09]

Here are some comments about raw_channel.* and message_pipe_dispatcher. (Need to
do more reading.)

https://codereview.chromium.org/1350023003/diff/140001/base/win/object_watcher.h
File base/win/object_watcher.h (right):

https://codereview.chromium.org/1350023003/diff/140001/base/win/object_watche...
base/win/object_watcher.h:64: // If |wait_many| is true, then this calls the
callback each time it's
I feel that "execute_only_once" may be more clear, because "wait many" sounds
like we are waiting on multiple handles.

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/messag...
File mojo/edk/system/message_pipe_dispatcher.cc (right):

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/messag...
mojo/edk/system/message_pipe_dispatcher.cc:129: // of the handle if the receiver
dies, since the broker can notice that.
(Just wonder whether you've come up with some new idea after our last discussion
on this topic.)
When the sender process sends a handle to the broker to get a token, does it
also somehow send "receiver" information to the broker? In the form of pid? We
may need to be careful about pid being recycled after a process is dead.

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/messag...
mojo/edk/system/message_pipe_dispatcher.cc:289: channel_ = nullptr;
This seems unintended because some places expect that this field is not cleared?

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/messag...
mojo/edk/system/message_pipe_dispatcher.cc:335: if
(channel_->GetSerializedPlatformHandleSize()) {
channel_ has been set to null on line 289?

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/messag...
mojo/edk/system/message_pipe_dispatcher.cc:379: rv->channel_ = channel_;
|channel_| has been set to nullptr in SerializeInternal().

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel.cc (right):

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel.cc:205: // read calls and we can't modify the
buffer.
I haven't understood this part yet: before ScheduleRead() on line 215, there
shouldn't be any pending read call, right?

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel.h (right):

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel.h:261: // Should only be called on the I/O thread.
Now that ReleaseHandle could be called on non-IO thread and it touches
read-related fields, we can no longer declare in the comments that read-related
fields are only accessed from the IO thread. Besides, we either need to append
"no_lock/NoLock" suffix to more methods, or remove the suffix from existing
methods.

(This comment applies to this class and also raw_channel_win.)

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel_win.cc (right):

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:388: OnIOCompleted(&write_context_,
write_context_.overlapped.InternalHigh,
Since write could happen on any thread, and we start watching on the
corresponding thread, it seems we can get this callback on any thread. However,
currently in OnWriteCompleted() we still DECHECK that it is called on the IO
thread. Have I missed anything?

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:482: (g_use_autoreset_event && error
==STATUS_PIPE_BROKEN)) {
It seems nice to unify the error code used.

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:719: // TODO(jam): right now we get in bad
situation where we might first write
I haven't understood: I thought we synchronously finish writing all pending
messages before trying to send a MP?

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:739: delete [] buf;
I think we need to keep the buffer valid until the operation is done, that is
why we preserve the read/write buffer during shutdown until I/O is completed or
canceled.

https://codereview.chromium.org/1350023003/diff/140001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:836: // This is hit when creating a duplicate
dispatcher since we don't call
Before this CL, Init() is restricted to be called on the IO thread because
basically there is only one raw channel and it is setup early at the startup of
the process.

Now that every message pipe owns a raw channel, maybe we should make Init() can
be called from any thread (or do it in the constructor), it can set up most of
the internal state properly. The only thing needs to be done on the IO thread is
start watching read.

That way we don't need to worry about the order of initialization and creating
equivalent dispatcher or shutdown. (We still need to take care of the case that
we haven't started watching read when creating equivalent dispatcher or
shutdown, but there are less things to consider that way.)

WDYT?

https://codereview.chromium.org/1350023003/diff/160001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel.cc (right):

https://codereview.chromium.org/1350023003/diff/160001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel.cc:453: base::AutoLock locker(read_lock_);
nit: use LoadAndCallOnError instead?

https://codereview.chromium.org/1350023003/diff/160001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel.cc:624: bool shutdown_called = false;
Shutdown() is no longer possible to be called from within
delegate_->OnReadMessage() because that results in a dead lock.

https://codereview.chromium.org/1350023003/diff/160001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel_win.cc (right):

https://codereview.chromium.org/1350023003/diff/160001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:260: BOOL rv = GetOverlappedResult(
Please add a comment about why the if (pending_read_)/if (pending_write_) blocks
are needed.

https://codereview.chromium.org/1350023003/diff/160001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:488: read_buffer()->Reset();
Before we cancel IO (which happens in io_handler_->ReleaseHandle()), we cannot
access the buffer contents, because the OS may be changing it outside of our
read_lock.

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel_win.cc (right):

https://codereview.chromium.org/1350023003/diff/280001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_win.cc:328: // Since this is called on the IO
thread, no locks needed for owner_.
I think this is not necessarily called from the IO thread because write can
start watching on any thread, right?

[jam, 2015-09-29 03:56:04]

Patchset #25 (id:440001) has been deleted

[jam, 2015-09-29 03:56:07]

Patchset #25 (id:440001) has been deleted

[jam, 2015-09-29 03:56:36]

Patchset #23 (id:400001) has been deleted

[brettw, 2015-09-30 03:56:11]

brettw@chromium.org changed reviewers:
+ brettw@chromium.org

[brettw, 2015-09-30 03:56:14]

https://codereview.chromium.org/1350023003/diff/480001/mojo/edk/embedder/BUIL...
File mojo/edk/embedder/BUILD.gn (right):

https://codereview.chromium.org/1350023003/diff/480001/mojo/edk/embedder/BUIL...
mojo/edk/embedder/BUILD.gn:12: "//mojo/edk/system",
This refers to the exact target //mojo/edk/system:system. I think what you want
is to match all targets in the directory hierarchy: //mojo/edk/system/*

[jam, 2015-09-30 19:42:54]

jam@chromium.org changed reviewers:
- brettw@chromium.org

[yzshen1, 2015-10-02 17:32:18]

LGTM

I only finished reviewing the message pipe and raw channel code. I don't think I
have any major concerns about landing this CL. I can take my time reading the
other code inside the codebase without blocking you. (I am still busy chasing
some multi-process failure, in the hope that I can make it more stable to pass
all page cycler test cases.)

https://codereview.chromium.org/1350023003/diff/620001/mojo/edk/system/raw_ch...
File mojo/edk/system/raw_channel_posix.cc (right):

https://codereview.chromium.org/1350023003/diff/620001/mojo/edk/system/raw_ch...
mojo/edk/system/raw_channel_posix.cc:507: bool
RawChannel::IsOtherEndOf(RawChannel* other) {
nit: passing |this| as argument to this method will return true.

[jam, 2015-10-02 20:09:48]

The CQ bit was checked by jam@chromium.org

[commit-bot: I haz the power, 2015-10-02 20:12:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1350023003/620001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1350023003/620001

[commit-bot: I haz the power, 2015-10-02 20:30:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-02 20:30:40]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[jam, 2015-10-02 20:53:57]

The CQ bit was checked by jam@chromium.org

[commit-bot: I haz the power, 2015-10-02 20:56:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1350023003/620001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1350023003/620001

[commit-bot: I haz the power, 2015-10-02 21:01:40]

Committed patchset #32 (id:620001)

[commit-bot: I haz the power, 2015-10-02 21:02:26]

Patchset 32 (id:??) landed as
https://crrev.com/76bcf0c21e332c08ee7a1601d0c878d1c75541a0
Cr-Commit-Position: refs/heads/master@{#352123}

[Will Harris, 2015-10-04 04:07:06]

On 2015/10/02 21:02:26, commit-bot: I haz the power wrote:
> Patchset 32 (id:??) landed as
> https://crrev.com/76bcf0c21e332c08ee7a1601d0c878d1c75541a0
> Cr-Commit-Position: refs/heads/master@{#352123}

Has this cl broken XP?
https://code.google.com/p/chromium/issues/detail?id=539043

[yzshen1, 2015-10-04 04:19:56]

On 2015/10/04 04:07:06, Will Harris wrote:
> On 2015/10/02 21:02:26, commit-bot: I haz the power wrote:
> > Patchset 32 (id:??) landed as
> > https://crrev.com/76bcf0c21e332c08ee7a1601d0c878d1c75541a0
> > Cr-Commit-Position: refs/heads/master@{#352123}
> 
> Has this cl broken XP?
> https://code.google.com/p/chromium/issues/detail?id=539043

Please see:https://codereview.chromium.org/1389513002/

[brucedawson, 2015-10-05 16:50:23]

brucedawson@chromium.org changed reviewers:
+ brucedawson@chromium.org

[brucedawson, 2015-10-05 16:50:26]

https://codereview.chromium.org/1350023003/diff/620001/mojo/edk/system/core.cc
File mojo/edk/system/core.cc (right):

https://codereview.chromium.org/1350023003/diff/620001/mojo/edk/system/core.c...
mojo/edk/system/core.cc:558: if (result_index && result_index)
The /analyze builder points out that this line of code is wrong or confusing.
The same condition is checked twice. I'm not sure what the intent is. The
warning, FWIW, is:

src\mojo\edk\system\core.cc(549) : warning C6287: Redundant code:  the left and
right sub-expressions are identical.

https://codereview.chromium.org/1350023003/diff/620001/mojo/edk/system/messag...
File mojo/edk/system/message_pipe_dispatcher.cc (right):

https://codereview.chromium.org/1350023003/diff/620001/mojo/edk/system/messag...
mojo/edk/system/message_pipe_dispatcher.cc:214: ScopedPlatformHandleVectorPtr
platform_handles;
This shadows the platform_handles function parameter which may lead to future
confusion or errors.

[Nico, 2015-10-08 02:00:23]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2015-10-08 02:00:26]

It looks like this breaks building all targets in component builds:

http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29/build...

FAILED: E:/b/depot_tools/python276_bin/python.exe gyp-win-tool link-wrapper
environment.x64 False link.exe /nologo /IMPLIB:./mojo_system_impl.dll.lib /DLL
/OUT:./mojo_system_impl.dll /PDB:./mojo_system_impl.dll.pdb
@./mojo_system_impl.dll.rsp
interface_control_messages.mojom.obj :error LNK2001: unresolved external symbol
"public: __cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
(??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)

master.mojom.obj :error LNK2001: unresolved external symbol "public: __cdecl
mojo::internal::LogMessage::LogMessage(int,char const *,int)"
(??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)

router.obj :error LNK2001: unresolved external symbol "public: __cdecl
mojo::internal::LogMessage::LogMessage(int,char const *,int)"
(??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)

string_serialization.obj :error LNK2001: unresolved external symbol "public:
__cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
(??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)

validation_errors.obj :error LNK2001: unresolved external symbol "public:
__cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
(??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)



etc. I guess some of the new targets need to be excluded in component builds
again – can you take a look?

[jam, 2015-10-08 22:27:31]

On 2015/10/08 02:00:26, Nico (offline until Fri Oct 9) wrote:
> It looks like this breaks building all targets in component builds:
> 
>
http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29/build...
> 
> FAILED: E:/b/depot_tools/python276_bin/python.exe gyp-win-tool link-wrapper
> environment.x64 False link.exe /nologo /IMPLIB:./mojo_system_impl.dll.lib /DLL
> /OUT:./mojo_system_impl.dll /PDB:./mojo_system_impl.dll.pdb
> @./mojo_system_impl.dll.rsp
> interface_control_messages.mojom.obj :error LNK2001: unresolved external
symbol
> "public: __cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
> 
> master.mojom.obj :error LNK2001: unresolved external symbol "public: __cdecl
> mojo::internal::LogMessage::LogMessage(int,char const *,int)"
> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
> 
> router.obj :error LNK2001: unresolved external symbol "public: __cdecl
> mojo::internal::LogMessage::LogMessage(int,char const *,int)"
> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
> 
> string_serialization.obj :error LNK2001: unresolved external symbol "public:
> __cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
> 
> validation_errors.obj :error LNK2001: unresolved external symbol "public:
> __cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
> 
> 
> 
> etc. I guess some of the new targets need to be excluded in component builds
> again – can you take a look?

doh, sorry about that. I'll look into this shortly.

[Nico, 2015-10-09 16:59:39]

any luck?

On Thu, Oct 8, 2015 at 3:27 PM, <jam@chromium.org> wrote:

> On 2015/10/08 02:00:26, Nico (offline until Fri Oct 9) wrote:
>
>> It looks like this breaks building all targets in component builds:
>>
>
>
>
>
http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29/build...
>
> FAILED: E:/b/depot_tools/python276_bin/python.exe gyp-win-tool link-wrapper
>> environment.x64 False link.exe /nologo /IMPLIB:./mojo_system_impl.dll.lib
>> /DLL
>> /OUT:./mojo_system_impl.dll /PDB:./mojo_system_impl.dll.pdb
>> @./mojo_system_impl.dll.rsp
>> interface_control_messages.mojom.obj :error LNK2001: unresolved external
>>
> symbol
>
>> "public: __cdecl mojo::internal::LogMessage::LogMessage(int,char const
>> *,int)"
>> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
>>
>
> master.mojom.obj :error LNK2001: unresolved external symbol "public:
>> __cdecl
>> mojo::internal::LogMessage::LogMessage(int,char const *,int)"
>> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
>>
>
> router.obj :error LNK2001: unresolved external symbol "public: __cdecl
>> mojo::internal::LogMessage::LogMessage(int,char const *,int)"
>> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
>>
>
> string_serialization.obj :error LNK2001: unresolved external symbol
>> "public:
>> __cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
>> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
>>
>
> validation_errors.obj :error LNK2001: unresolved external symbol "public:
>> __cdecl mojo::internal::LogMessage::LogMessage(int,char const *,int)"
>> (??0LogMessage@internal@mojo@@QEAA@HPEBDH@Z)
>>
>
>
>
> etc. I guess some of the new targets need to be excluded in component
>> builds
>> again –&nbsp;can you take a look?
>>
>
> doh, sorry about that. I'll look into this shortly.
>
> https://codereview.chromium.org/1350023003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.