Global Resource Coordinator: Basic service internals

services/resource_coordinator/public/cpp/coordination_unit_struct_traits.h

Index: services/resource_coordinator/public/cpp/coordination_unit_struct_traits.h
diff --git a/services/resource_coordinator/public/cpp/coordination_unit_struct_traits.h b/services/resource_coordinator/public/cpp/coordination_unit_struct_traits.h
new file mode 100644
index 0000000000000000000000000000000000000000..dfbe719005d26a8b1c709b88b887d937233c8e5e
--- /dev/null
+++ b/services/resource_coordinator/public/cpp/coordination_unit_struct_traits.h
@@ -0,0 +1,29 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_COORDINATION_UNIT_STRUCT_TRAITS_H_
+#define SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_COORDINATION_UNIT_STRUCT_TRAITS_H_
+
+#include "ipc/ipc_message_macros.h"
+#include "ipc/param_traits_macros.h"
+#include "services/resource_coordinator/public/cpp/coordination_unit_events.h"
+#include "services/resource_coordinator/public/interfaces/coordination_unit.mojom.h"
+
+IPC_ENUM_TRAITS_MIN_MAX_VALUE(

[Ken Rockot(use gerrit already), 2017/04/10 23:58:00]

I am thoroughly confused. Why are you introducing a typemap and traits for these
enums? Why not just define the enum in mojom and have consumers use the
generated enum type directly?

[oystein (OOO til 10th of July), 2017/04/11 00:11:56]

Separate reasons for each enum basically:
* For the events, I'm expecting the number of different ones to grow to a
sizable amount over time. As far as I can tell every modification to a .mojom
file requires a security lgtm, which seems unnecessary for new enum entries and
I'm worried about a chilling effect on utilizing this. Is there an accepted way
to avoid needing security LGTM's on new enum entries (as in not do the per-file
*mojom=file:/securitypeople thing for mojom with just the enum), or is there a
good reason for having them still?

* For the type, skyostil@ and lucky-luke folks wants to use CoordinationUnits
for cost attribution at a fairly basic scheduler level; essentially
CoordinationUnits which are too granular to have their own messagepipes but will
have a parent channel to push events through (this is fairly preliminary plans
btw, still under discussion). I made the type and the CoordinationUnitID struct
a native type as it's then likely to be needed under //base, but maybe they can
comment on whether that'll likely be needed or not [hereby poking skyostil@ +
chrisha@]. That said, we're not likely to add new types as frequently as we do
new events, so I don't mind having both a native struct and a mojom struct that
we typemap between if that's the preferred way.

+    resource_coordinator::EventType,
+    resource_coordinator::EventType::INVALID_EVENT,
+    static_cast<size_t>(resource_coordinator::EventType::NUM_EVENTS) - 1)
+
+IPC_ENUM_TRAITS_MIN_MAX_VALUE(
+    resource_coordinator::CoordinationUnitType,
+    resource_coordinator::CoordinationUnitType::INVALID_TYPE,
+    static_cast<size_t>(resource_coordinator::CoordinationUnitType::NUM_TYPES) -
+        1)
+
+IPC_STRUCT_TRAITS_BEGIN(resource_coordinator::CoordinationUnitID)
+  IPC_STRUCT_TRAITS_MEMBER(type)
+  IPC_STRUCT_TRAITS_MEMBER(id)
+IPC_STRUCT_TRAITS_END()
+
+#endif  // SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_COORDINATION_UNIT_STRUCT_TRAITS_H_