New issue
Advanced search Search tips

Issue 733631 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 705982



Sign in to add a comment

Should //components/tracing support iOS?

Project Member Reported by blundell@chromium.org, Jun 15 2017

Issue description

Currently //components/tracing is not iOS-friendly AFAICT (e.g., assumes use of IPC and multiprocess). As we integrate services on iOS (see parent bug), I assume that we're going to want the functionality that //components/tracing provides on iOS?
 
Cc: oysteine@chromium.org chiniforooshan@chromium.org
All the //components/tracing stuff is a result of historical evolution, pulled by weird cases like nacl.
We are moving both tracing and memory-infra to services and my expectation is that folder will be slowly emptied and disappear (and if not disappear, will at most contain optional bits that are not critical for the operation of tracing)

Tracing servicification doc:
https://docs.google.com/document/d/1osLqctK_rTiioKFOG9wDLkrCQ9DLJZmm4j-S335u-vM/edit

Memory-infra servicification doc:
https://bit.ly/memory-infra-service

Having said that, at the moment iOS is not on top of the priority list for tracing. chiniforooshan@ here is driving the tracing servicification effort and, AFAIK, his driving priority is MUS+ASH right now. But if we do everything correctly I expect iOS to just work (or be able to work with some minimal effort by some iOS champion)
This makes sense, thanks! Is there a tracking bug for the tracing service? If so, I can just hang a bug off it that says "Support tracing service on iOS".
Re #2:  Issue 640235 
Status: WontFix (was: Available)
Thanks, filed  crbug.com/734561  and closing this one out.

Sign in to add a comment