Confirmed users
125
edits
(→Data) |
(→Data) |
||
Line 116: | Line 116: | ||
Images Images | Images Images | ||
Based on the current code, the earliest it is conceivably possible to run B2G would be in the early-init stage of init.rc. This stage was observed to be executing at around 4.8s of uptime. Realistically a lot of things would need to be changed for this to work (that is to say, a lot of things break when this is attempted). A more logical stage would be early-boot (which is not used in the default init script, however is a supported stage that occurs between post-fs-data and boot). What is notable about this stage is that, A.) if done here, B2G launches at around 5.8s and B.) It successfully runs. Sometimes. There are clearly some dependencies that are not quite guaranteed to be ready if one attempts to launch B2G this early, which could be the subject of a future investigation to see if those dependencies could be made to occur any earlier. But as it stands, this only launches B2G around 2 seconds earlier. | Based on the current code, the earliest it is conceivably possible to run B2G would be in the early-init stage of init.rc. This stage was observed to be executing at around 4.8s of uptime. Realistically a lot of things would need to be changed for this to work (that is to say, a lot of things break when this is attempted). A more logical stage would be early-boot (which is not used in the default init script, however is a supported stage that occurs between post-fs-data and boot). What is notable about this stage is that, A.) if done here, B2G launches at around 5.8s and B.) It successfully runs. Sometimes. There are clearly some dependencies that are not quite guaranteed to be ready if one attempts to launch B2G this early, which could be the subject of a future investigation to see if those dependencies could be made to occur any earlier. But as it stands, this only launches B2G around 2 seconds earlier. and there actually was no decrease in overall boot time observed (again dependencies not being respected comes to mind as an explanation). | ||
[http://people.mozilla.org/~jbailey/v121-2-lesswreckless/ Related Data]. Not as many trials were done because these were just cursory feasibility tests. | |||
One will note that in the first 13 trials B2G tries to launch, crashes, and then relaunches at around 12s, whereas it starts fine for the last 3. | One will note that in the first 13 trials B2G tries to launch, crashes, and then relaunches at around 12s, whereas it starts fine for the last 3. In particular one can search for the string OPTBOOT in the kmsg.N and logcat.N files for a look at the timings of a few important points. | ||
<pre> | |||
in kmsg: | |||
|OPTBOOT: INIT START| | |||
represents (close to) the entry point of init's main | |||
in both: | |||
|OPTBOOT: Starting B2G| | |||
represents the b2g service being started. This is also shared with logcat, since this time is | |||
also used to synchronize with the logcat log which is only reported in terms of absolute time. | |||
This is needed since once one gets high enough in the application layer | |||
it becomes very difficult to message the kernel logs. | |||
in logcat: | |||
|Content JS LOG at app://verticalhome.gaiamobile.org/js/app_manager.js:126 in anonymous: OPTBOOT: Vertical: app_manager.js:126| | |||
A message from javascript-land. In particular near the entry point for the Vertical Homescreen application. | |||
It should be noted that this occurs around a second or so before things are put on the screen. | |||
</pre> | |||
In the trials for which b2g survives, if one calculates the offset from boot of the Vertical home screen log message, one sees that it is about 24s as opposed to 26s in the trials it crashes. | |||
==References== | ==References== | ||
[https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Firefox OS Bootup Procedure] | [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Firefox OS Bootup Procedure] |