Method, non-volatile computer-readable storage medium and computer system for improving a hibernation and resumption process by means of user-room synchronization

Abstract

Before a computer device (102) enters hibernation, system software components (116) are notified of an impending hibernation process. The notifications are transmitted via an application programming interface (API) (114). At least some of the system software components (116) can perform one or more pre-hibernation activities to prepare the system software component (116) for resumption. Each system software component indicates when it is ready for hibernation. In response to receiving the indication from each of the system software components (116), the hibernation process can be completed. The completed hibernation process generates a snapshot (122) in non-volatile memory. The snapshot (122) saves state information (124) for each of the system software components (116).The status information (124) is intended for the readiness state for resuming the system software components (116). The computer device (102) can be restored after hibernation by means of a resumption process (130) that reads the status information (124) from the snapshot (122).

Description

AREA OF REVELATION

[0001] The present invention relates generally to managing a power-on process for communication devices, and more particularly to a method and apparatus for enhancing a hibernation and resumption process using user space synchronization. BACKGROUND

[0002] Hibernation and resume processes of computing devices are increasingly being used to achieve short boot times and minimize waiting time for users. Hibernation allows a state of a computing device to be saved and then allows the computing device to be shut down. This means that software processes running under a computing device's operating system can be "frozen" or saved in a snapshot, with the snapshot being stored in non-volatile memory.

[0003] A variety of events can cause a hibernation process to place a computing device into a state in which one or more system parameters or values ​​are in error. For example, many devices include mechanical controls, knobs, selectors, and the like. These mechanical controls may be in one position when a hibernation process is running and in a different position when a resume process is running. Each setting of a mechanical control may have an associated value maintained in volatile memory via an operating system data structure. If one or more internal values ​​for a current state of the device are in error, a variety of adverse outcomes can occur.

[0004] For example, the device may detect the erroneous value and correct it, thereby increasing a processing time of the resume process and / or adding a user-perceivable delay that impacts a user experience with the computing device. In another example, erroneous values ​​established during a resume process may result in erratic device behavior (i.e., an erroneous volume if the mechanical control is dedicated to a volume; an erroneous state if the mechanical control is dedicated to a communication state; etc.). In yet another example, erroneous values ​​from a resume process may cause software crashes and other unexpected errors.

[0005] From the publication US 2012 / 0 036 346 A1, a partial restoration of the hibernation state to shorten the boot time is known.

[0006] The object of the present invention is to improve the hibernation and resumption process, minimizing or eliminating problems with parameter values ​​that are erroneous when restoring from a snapshot. This object is achieved by the subject matter of the respective independent patent claims. SHORT DESCRIPTION OF THE CHARACTERS Fig. 1 is a block diagram for enhancing a hibernation and resumption process according to embodiments of the disclosure. Fig. 2 is a flowchart for methods for improving a hibernation and resumption process according to an embodiment of the inventive arrangements disclosed herein. Fig. 3 shows a message sequence diagram of a freezing / hibernation process according to an embodiment of the inventive arrangements disclosed herein. Fig. 4 shows a message sequence diagram of a thawing / resuming process according to an embodiment of the inventive arrangements disclosed herein. Fig. 5 is a schematic diagram illustrating a system for implementing a hibernation and resumption process according to embodiments of the disclosure. DETAILED DESCRIPTION

[0007] A method, apparatus, system, and / or computer program product for hibernation and resumption processes for a computing device. According to the disclosure, prior to hibernating a computing device, system software components may be notified of the impending hibernation process. In one embodiment, the notifications are communicated via an application programming interface (API). At least a portion of the system software components may perform one or more pre-hibernation activities to place the system software component into a ready state for resumption. Each system software component may indicate when it is ready for hibernation. In response to receiving an indication from each of the system software components indicating that each of the system software components is ready for hibernation, the hibernation process may be completed.The completed hibernation process creates a snapshot in non-volatile memory. This snapshot saves state information for each system software component. This state information is intended for the system software components' ready state for resumption.

[0008] The disclosure supports the fact that snapshots saved thereby launch system software components at a meaningful and desired point of execution (e.g., in a ready state for resumption). In other words, previous snapshot solutions used for hibernation / resume processes attempt to capture a system state at an arbitrary point, resulting in system software components not being given an opportunity to prepare for hibernation (i.e., no pre-hibernation activity occurs for system software).According to the disclosure, placing the system software components in a ready-for-resume state ensures that processes for each of the system software components are started at a particular point of execution, for example, at or near an execution location where initialization code of the system software component is executed.

[0009] In some embodiments, the ready-for-resume state of the software applications can be intentionally saved and reused upon request. For example, a set of one or more snapshot images can be created in a factory even before a machine is shipped and sold (or when the machine's operating system is loaded). Additionally, a new "baseline" or "reference" snapshot can be created when system software components, the operating system, and / or hardware of a machine are upgraded. A reliable snapshot can enable a machine to boot up more quickly because the system software components do not need to boot from a "cold" state, but can be loaded directly (from non-volatile memory to volatile memory) in a warm state (e.g., the ready-for-resume state), thereby reducing the overall machine power-on time.In one embodiment, power-on time can be further improved by powering on a subset of the system software components that provide a desired core functionality to the computing device, and then subsequently powering on the remaining system software components. That is, in contemplated embodiments, the resumption process can be optimized to occur in a staged manner, with functionality provided to the end user at each stage. In one embodiment, a machine can utilize the snapshot comprising "resume-ready" system software components for rapid recovery from fault conditions simply by powering on and resuming from a snapshot.

[0010] Fig. Figure 1 is a block diagram for enhancing a hibernation 120 and a resumption 130 process according to embodiments of the disclosure. The disclosure also utilizes snapshots of system software components placed in a ready-for-resume state for many situations. Snapshots such as those used herein are not limited to those generated by a user-initiated hibernation process, but also include those generated in a factory, those generated in response to a system upgrade, and / or those generated when a system detects that no "reference" or "home" snapshot exists.Unlike conventional prior art hibernation processes, in hibernation process 120, system software components 116 of an operating system 110 are notified that a hibernation process has been initiated before a snapshot 120 is created (or the snapshot 122 is created in a factory or at another time while the system software components 116 are in a ready state for resumption).

[0011] System software components 116 may include applications, processes, and drivers that maintain state information in volatile memory (e.g., random access memory or RAM). This allows each system software component 116 to prepare itself for hibernation by executing one or more pre-hibernation activities that place the system software in a ready state for resumption. Not all system software components 116 necessarily need to execute a pre-hibernation activity before each operational state. After optionally executing pre-hibernation activities, each notified system software component 116 may report that it is ready for hibernation. When all notified components have reported that they are ready to hibernate, a snapshot creation action 119 may be triggered, which creates a snapshot 122.In one embodiment, the pre-hibernation actions may occur in user space 113 while a hibernation process 110 is initiated from kernel space 111 and while the snapshot 122 is created by a process executing in kernel space 111.

[0012] A snapshot 122 is generated in response to many different events, according to various contemplated embodiments of the disclosure. For example, the hibernation action is initiated by a user action to perform hibernation. In another example, the hibernation action is initiated by a timeout period associated with hibernation. In yet another example, the hibernation action is initiated by a system detection at boot time that an existing reference is missing (in this latter case, shutdown actions often associated with a hibernation process need not occur). These examples are not exhaustive, and others are contemplated.

[0013] In one embodiment, notifications about the hibernation action are initiated by an application programming interface (API) 114 configured for hibernation / resume operations 120, 130. A notification function such as "get_ready()" may be used for this purpose. Once the notifications have been sent from an API 114, messages may be passed back to the API 114 from any of the system software components 116. For example, a function such as the illustrated "report_ready()" function or an equivalent may be used for this purpose. Using an API 114 for messages to the system software components 116 may be a useful standardized approach, particularly for hibernation / resume operations 120, 130 implemented within a kernel space 111 of the operating system 110 and / or those implemented at a BIOS level of the computing device 102.

[0014] The resume process 130 may be initiated by many different events and for different situations or purposes according to various contemplated embodiments of the disclosure. For example, the resume process 130 occurs at system startup to enable a "quick boot." In another example, the resume process 130 occurs from a hibernation, sleep, or other power-saving state of a computing device 102. In yet another example, the resume process 130 is triggered by a system failure (triggering a power-on and then resume, or triggering a system reset / restore and then resume).Similarly, the resume process 130 may be triggered by any exception event as part of a recovery process from an unknown state, from erroneous behavior, and the like (i.e., the resume process 130 from a known snapshot may occur as part of an exception handling process). In one embodiment, different snapshots 122 (e.g., a reference snapshot, a recovery snapshot, and the like) may be stored by the computing device 102 and associated with the different resume process situations.

[0015] Regardless, once the resume process 130 is initiated, power-up actions (if needed) are taken to restore power to the system components. The snapshot 122, stored in non-volatile memory, is accessed and read, thereby loading previously stored state information 124 into volatile memory. Unlike prior art implementations, the saved state 124 is one that previously executing software system components 116 have been able to prepare by operationally performing a set of pre-hibernation actions, thereby placing the version of each of the system software components 116 stored by snapshot 122 into a ready state for resume.Thus, compared to conventional hibernation processes, system software components 116 are less likely to experience synchronization problems when resuming from hibernation. For example, the resume ready state for system software components 116 may be a state that exists immediately before acquiring variables that may change during a hibernation shutdown period (for example, values ​​associated with a mechanical control of device 112 may be initiated from the resume ready state).Similarly, the resume ready state may be positioned at an execution location where the operating system 110 checks whether changes have occurred to removable peripheral devices (for example, a Universal Serial Bus or other plug-and-play devices) before taking actions that depend on those devices.

[0016] In one embodiment, time ordering and dependencies between variables of the operating system 110 and / or the system software components 116 may be considered. Thus, variables, values, and other messages may occur between the system software components 116 and the operating system 110 during the resume process 130. For example, different ones of the system software components 116 may include a set of multiple processes and / or even child processes. For example, one of the software components 116 may include processes A, B, and C and child processes A1 and B1, as shown. These processes and child processes may be ordered relative to each other and / or to other running processes or child processes of the operating system 110.State-saved variables 124 may require that these time series be correctly sequenced and / or synchronized with each other, which is possible in the disclosure due to software components 116 being capable of performing pre-hibernation activities to place each into a ready-for-resume or execution position before taking snapshot 122. Proper sequencing simply ensures that a proper state 124 is reached, as specified in snapshot 122. Furthermore, pre-hibernation activities may include optimizations designed to quickly return a computing device 102 to its previous state (or to a default, reference, or baseline state) upon executing a resume process 130.

[0017] In the hibernation process 120, each of the system software components 116 is in a random state when a hibernation preparation message is received. Pre-hibernation activities transition each of the system software components 116 from this random state to a ready-for-resume state. In one case, a ready-for-resume state may be a state in which software components 116 are prepared to perform initialization actions upon resumption (e.g., resumption process 130). For example, a system software component 116 may be transitioned to a ready-for-resume state by moving the execution pointer to perform an initialization action upon resumption.It should be appreciated that the hibernation process 120 may include one or more modes of operation, including a protected mode of operation and a supervised mode of operation, where the different modes of operation may have an effect on pre-hibernation activities performed by the system software components 116.

[0018] Generally, the hibernation process 120 is one in which the computing device 102 is able to power down while retaining its state information (e.g., state 124). In one embodiment, the power down process is optional, while saving the state information to a snapshot 122 is required. That is, upon hibernation, the computing device 102 saves contents of its volatile memory (e.g., random access memory or RAM) to non-volatile memory as a snapshot 122. The computing device 102 may then, in one embodiment, be completely powered down, which conserves power. The resumption process 130 causes the computing device 102 to power up and then retrieve the saved state information 124 from the snapshot 122.

[0019] The hibernation process 120 used herein can be distinguished from a sleep process in that a sleep process provides power to non-volatile memory so that stored state information is retained, thereby obviating the need to save the state information 124 to a snapshot 122 (i.e., non-volatile memory). Techniques for notifying system software components can be applied to a sleep process, as well as to a hibernation process 120, as detailed herein. Moreover, the hibernation process 120 of the disclosure can be a hybrid hibernation / sleep process in which content is copied from volatile memory to non-volatile memory as a snapshot when the computing device 102 enters a sleep mode, thereby allowing state recovery even if power to the device 102 is lost.In one embodiment, the hibernation 120 and resumption 130 processes are intended to be substantially compliant with the Advanced Configuration and Power Interface (ACPI) specification. In other contemplated embodiments, the ACPI specification itself may be extended to include innovations detailed herein. Alternatively, the hibernation 120 and resumption 130 processes may be implemented in a proprietary manner compliant with the ACPI specification. It should be noted that situations are contemplated (such as failure recovery using a previously saved snapshot 122) where a resumption process 130 does not require that a hibernation process 120 occur, but only requires that a suitable snapshot 120 be present.

[0020] Operating system 110 may refer to a set of executable code that can manage computer hardware resources and provide common services. Operating system 110 may include low-level hardware device drivers.

[0021] In one embodiment, operating system 110 may be represented as a virtual memory representation of physical memory (RAM), which divides the operating system into kernel space 111 and user space 113. Kernel space 111 may include virtual memory reserved for executing kernel 112, kernel 112 extensions (e.g., modules), device drivers, and the like. For example, kernel space 111 may be used to perform kernel 112 operations. Kernel 112 may, but need not, include a monolithic kernel, a microkernel, a hybrid kernel, a modular kernel, a nanokernel, an exokernel, and the like.

[0022] User space 113 may include virtual memory used to execute system software components, which may not necessarily include a hibernating application programming interface (API) 114, system software components 116, drivers, auxiliary software, and the like. User space 113 may include multiple processes (e.g., process A, process B) and child processes (e.g., child processes A1 and B1) associated with system services (e.g., network services, directory services, etc.).

[0023] API 114 represents a collection of functionalities that enable enhanced hibernation and resumption processes 120, 130 described herein. API 114 enables a user space system software components 116 to enter a ready state for resumption before hibernation occurs. API 114 may, but need not, include a library, framework, and the like. API 114 may be compatible with conventional and / or proprietary languages, including, but not limited to, C, C++, Java, and the like.

[0024] Each of the system software components 116 may be a component executable within a user space 113. Each component 116 manipulates and / or consumes hardware and / or software resources of the computing device 102. System software components 116 may, but need not, include a process, a thread, a daemon, and the like. That is, system software components 116 may include a set of one or more processes (e.g., process A, process B), child processes (e.g., child processes A1 and B1), and the like. In one case, system software components 116 share hardware and / or software constructs with other system software components 116 to execute during an execution state. For example, a process A and a process B associated with one or more software components 116 may utilize a semaphore to communicate with each other.In one embodiment, API 114 provides functionality for detecting and handling process exceptions. In the embodiment, API 114 detects and responds appropriately to an unresponsive process (e.g., a zombie process), a memory leak, a suspended process, and the like.

[0025] The snapshot 122 may be a process image reflecting the ready-for-resume state of the system software components 116. In one case, the state 124 information of the snapshot 122 includes an exact replica of a process control block associated with the system software components 116, approximately at a time when the snapshot 122 was taken. The state information 124 may include, but is not limited to, process states, states of child processes, object information (e.g., object state), address information (e.g., execution pointer, data pointer), process identification number (e.g., PID), register contents, flag state, switch state, address space information (e.g., upper and lower memory bounds), open files, process priority, I / O device state, and the like.

[0026] In one embodiment, snapshot 122 is used to restore the system software component 116 state independently of the previous state. That is, snapshot 122 is used to enable a reusable image that can be used to quickly restore one or more of the software components 116 to a specific state. In one case, a snapshot 122 is created at a manufacturing facility and can be used at each restart to restore the device to a factory-as-shipped state. When changes are made to the hardware configuration of computing device 102 and / or the software components 116, a "factory" or reference state of snapshot 112 is updated to reflect those changes.

[0027] Using a reference snapshot 122 can significantly reduce the time required for a hibernation process 120. Furthermore, in one embodiment, a "reference" hibernation state can be enriched with variable values ​​for an operating system of the system software components 116. These values ​​can be explicitly determined and made available to the snapshot 122 as part of preparing each of the system software components 116 for hibernation.

[0028] Fig. 2 is a flowchart for methods 201, 250 for enhancing a hibernation and resumption process according to one embodiment of the inventive arrangements disclosed herein. Method 201 is a hibernation process for a sequence of steps intended for suspending an operating system or system software. As previously noted, there may be snapshots created by processes other than hibernation process 201, such as "born-ready" snapshots created in a factory and shipped with a machine. Method 250 is a resumption process for a sequence of steps intended for resuming an operating system and / or system software from a snapshot stored in non-volatile memory.

[0029] Hibernation process 201 begins when a system message or notification is sent to running software components, informing those components that a hibernation process has been initiated. In response to receiving this notification or message, each software component may perform a set of pre-hibernation actions to place itself in a ready state for resumption. For example, and as shown in step 205, a system component detects a hibernation event and / or notification. This notification may occur in various ways. In one embodiment, there may be a TIF_FREEZE flag for initiating a hibernation preparation process.

[0030] In an alternative embodiment, a non-hibernation event may be substituted to trigger snapshot creation; however, this does not necessarily result in a computing device entering a power-off or low-power mode. For example, if no basic snapshot is detected for a computing device during charging, a snapshot creation event may be automatically triggered in one embodiment of the disclosure.

[0031] In step 210, a preparation or pre-hibernation (or pre-snapshot creation) action associated with the hibernation event is initiated by the software content. The preparation action may include: pausing thread creation, consolidating memory usage, clearing a cache, flushing a queue / buffer, and the like. In step 215, notification of the pending hibernation action is optionally communicated to dependent processes. In step 220, one or more processes or child processes of the software component may release one or more in-use resources. For example, as part of a hibernation preparation process, a software component may release mutually exclusive resources before hibernating.In step 225, the method continues with step 230 if the software component is ready for hibernation (e.g., if all pre-hibernation activities have been performed). Otherwise, additional pre-hibernation activities are performed for that software component, as expressed by the method proceeding from step 225 to step 210.

[0032] In step 230, the software component has reached a ready state for resumption. In one embodiment, this may be a "special state" in which the software component no longer responds to requests other than a resumption request. In step 240, the software component sends a notification that it is ready for hibernation. Steps 205 through 240 may be performed by any running software component.

[0033] The hibernation process may be delayed until all software components have reported that they are ready for hibernation, as shown by the delay loop of decision block 242. In one embodiment, timeout checks are provided to ensure that a hibernation activity is aborted as unsuccessful after a predetermined period of time has elapsed. In another embodiment, after a timeout period to respond, a hibernation activity occurs even if not all software components have reported that they are ready for hibernation. Once all software components are ready for hibernation (or a timeout period has elapsed), hibernation is initiated, creating a snapshot, as shown by step 244.

[0034] The resume process 250 begins in step 255, where a resume notification is received from an operating system. In step 260, an appropriate snapshot is selected based on the notification. In one case, the notification enables the system software to resume without error when executing within an operating system that supports multiple operating modes or users, where the appropriate snapshot is specific to a current operating mode or user. In another case, the selected snapshot may be a special snapshot, such as a baseline / baseline snapshot, a boot-up snapshot, a recovery snapshot, and the like. In step 265, the snapshot is used to resume software execution.The snapshot may be used to return any system software component to its ready state for resume, as shown in step 270.

[0035] The resume ready state is one in which a software component is ready to resume, checking for unknown conditions that may change during hibernation. For example, the resume ready state of a software component is one in which that software component first reads the state of a mechanical control or switch and sets appropriate values ​​based on that read position. The resume ready state also checks an operating system state and whether necessary computer components (which may be disabled or disconnected from or reconnected to a computing device, such as USB peripherals) are in an expected state.If not, values ​​of this software component can be quickly set in an appropriate manner, in contrast to the software component attempting to operate depending on a resource that is unavailable, which is a known problem of software components frozen or hibernated in any execution state (as opposed to the new ready state for resumption).

[0036] It should be appreciated that different time sequences may be established for hibernating and / or resuming various system software components. That is, in one embodiment, a multi-stage hibernation / resume process is provided, in which various system software components may be required to wait until other system software components have reached an execution state before that component is "frozen" or "thawed" according to a staged hibernation / resume process. Thus, one system software component may be reactivated from a snapshot very quickly relative to another system software component.In one embodiment, software component-specific "THAW" and / or "FREEZE" or "RESUME" messages may be used to control timing and scheduling during hibernation 201 or resumption 250 processes.

[0037] Additionally, in one contemplated embodiment, a multi-stage hibernation / resume process ensures that each stage includes grouped subsets of system software components required to provide end-user functionality. This may enable "core functionality" of a computing device to be restored for end-user use as quickly as possible in response to an initiated resume process 250. For example, in a smartphone computing device, one stage may provide core phone functionality, a later stage may provide basic user interface functionality, and a final stage may provide functionality to access the network via a browser and / or non-essential applications installed on the device. Furthermore, in one contemplated embodiment, the multi-stage resume process 250 may be tailored to the situation.For example, if a recovery process 250 is triggered based on a fatal error (i.e., the recovery process 250 is used to recover from an error), then functionality that the user was using at the time of the error (if known) can be restored in a prioritized manner before functionality that the user was not using at the time of the error. This enables the end user to use the desired functionality as quickly as possible, meaning that the perceived or effective recovery time is minimized using a multi-stage recovery technique.

[0038] Fig. 3 shows a message sequence diagram 300 of a freeze / hibernate process according to one embodiment of the inventive arrangements disclosed herein. The message sequence diagram 300 shows a snapshot creation process during a boot sequence, as may occur automatically when no existing snapshot is stored for a computing device. The message sequence diagram 300 shows that a freeze daemon 316 is started during the boot process. The freeze daemon 316 may wait for messages from other components 318-326 of the system until they indicate that they are ready to be frozen. Once all of the components 318-326 have reported that they are ready, the freeze daemon 316 may send a message to the kernel 312 to start the freeze process.

[0039] To go into more detail in diagram 300, a boot message is sent from the boot loader 310 to the kernel 312. An initialization process 340, a boot driver process 342, a file mount system process 344, and a load initiator process 346 may be executed at the kernel 312. The initialization process 314 may boot Android® (or another operating system). As part of the initialization process 314, a freeze daemon 316, an audio system 318, a push-to-talk (PTT) handler 320, a dispatch audio handler 322, a dispatch application 324, and a DekTec Application Programming Interface (DTAPI) 326 may be started through a series of boot messages, as shown in diagram 300.The freeze daemon 316, the audio system 318, the push-to-talk (PTT) handler 320, the dispatch audio handler 322, the dispatch application 324, and the DekTec Application Programming Interface (DTAPI) 326 are illustrative system software components that vary in quantity and type from computing device to computing device, although others may also be considered.

[0040] Upon startup, the freeze daemon 316 waits for freeze messages from the other components 318-326. Each component 318-326 optionally performs a set of pre-hibernation or pre-snapshot activities, then sends a "FREEZE ME" message to the freeze daemon 316. By sending the "FREEZE ME" message, each component 318-326 indicates that it has placed itself in a ready-to-resume state. While in this ready-to-resume state, each component 318-326 may wait for a THAW UP message, as shown with the wait processes 352, 354, 356, 358, and 360, respectively.

[0041] The freeze daemon 316 sends a “FREEZE SYSTEM” message to the kernel 312, which then performs a system freeze 362.

[0042] Fig. Figure 4 shows a message flow diagram 400 of a thawing / resuming process according to one embodiment of the inventive arrangements disclosed herein. Message flow diagram 400 shows that during a power-on process, kernel 312 detects an image or snapshot and then loads it. After the image is loaded, the system resumes to a state in which it was previously frozen. The freeze daemon can inform all waiting components 320-326 that they can be thawed.

[0043] To elaborate on diagram 400, a boot message is sent from the boot loader 310 to the kernel 312. The kernel 312 may be running an initialization process 340 and a boot driver process 342. Then, an image or snapshot may be detected by a process 410 running in the kernel 312. The image may be loaded by process 412. A resume process may be initiated by process 412. Finally, a wake-up message may be sent from the kernel 312 to the freeze daemon. Unfreeze messages may be sent to any of the system software components 320-326 that were in a wait state 352-360 prior to the unfreeze message(s), as shown. The freeze daemon 316 may wait for a period of time (e.g., 3 seconds) after a post-unfreeze script is executed 420.

[0044] Fig.5 is a schematic diagram illustrating a system 500 for implementing a hibernation and resumption process according to embodiments of the disclosure.

[0045] As used herein, hibernation may include persisting system software component state information residing in volatile memory 524 into non-volatile memory 526, specifically into a snapshot 560. Resuming may include loading system software component state information from a stored snapshot 560 into volatile memory 524. In one embodiment, snapshot 560 is a digitally encoded data structure capable of persistently preserving software component state information.In various embodiments of the disclosure, not every snapshot 560 needs to be created by a hibernation process (i.e., some snapshots 560 may be "ready when produced"), and not every resumption process needs to occur from a hibernation state (i.e., the resumption process may occur from a sleep state, from a fault state, and the like).

[0046] Computing device 510 may be a hardware / software unit that enables execution of operating system 530. Device 510 may include hardware 512, software 514, firmware, and the like. In various embodiments, computing device 510 may be, but is not limited to, a mobile computing device, a cellular phone, a two-way radio, a laptop, a desktop computer, a tablet computer, a personal digital assistant, and the like.

[0047] Hardware 512 may, but need not, include a processor 520, a bus 522, volatile memory 524, non-volatile memory 526, and the like. Additional hardware components 512 (not shown) such as input / output devices, network transceivers, audio converters, and the like may also exist for computing device 510.

[0048] The software 514 may, but need not, include an operating system 530, system software 536, a snapshot 560, and the like.

[0049] The operating system (OS) 530 may, but need not, include a kernel 532, executable code 534, and the like. The operating system 530 may, but need not, include a graphics manager. In one embodiment, the operating system 530 may, but need not, include GNU LINUX, UNIX, WINDOWS®, and other operating systems that implement a hibernation / resume process.

[0050] Executable code 534 represents one or more sets of instructions for constructing user-space initialization for performing hibernation and resumption. Executable code 534 may, but need not, include a process manager 542, a snapshot handler 544, settings 546, and the like. The functionality of code 534 may, but need not, include power control of device 510, state transition functionality, and the like. For example, code 534 may be a user-space service capable of initiating hibernation preparation actions associated with system software 536.

[0051] Process manager 542 may be a piece of executable code capable of performing hibernation and resumption functionality within user space. Manager 542 functionality may, but need not, include process communication, process registration, process deregistration, and the like. In one case, manager 542 may be used to track process state. For example, manager 542 may query software 536 to determine hibernation readiness. In one embodiment, manager 542 may be configured to respond to software 536 errors. In one configuration of the embodiment, if software 536 hangs, manager 542 may determine an appropriate historical snapshot and automatically terminate the process. In the configuration, the historical snapshot may be used to restart the process upon resumption.In another configuration of the embodiment, if software 536 hangs, manager 542 may transmit a notification to a user interface. In one embodiment, manager 542 may use settings 550 to control hibernation and / or resumption. Settings 550 may represent state data saved for software components that respond to a hibernation process.

[0052] Snapshot handler 544 may be a software unit for handling a snapshot 560. Handler 544 functionality may, but need not, include snapshot 560 creation, snapshot 560 deletion, snapshot 560 manipulation, snapshot 560 retrieval, and the like. Handler 544 may utilize conventional and / or proprietary mechanisms to create and / or manage snapshot 560. In one case, handler 544 may utilize a process identifier to uniquely identify a snapshot with software. In one embodiment, handler 544 may employ conventional and / or proprietary compression mechanisms to enable a reduced snapshot size. In one embodiment, handler 544 may be utilized to compress and / or optimize snapshot 560.

[0053] Settings 546 may include one or more sets of rules for establishing the behavior of device 510, system 530, executable code 534, and / or system software 536. Settings 546 may, but need not, include a process manager 542, a snapshot handler 544, and the like. Settings 546 may be determined manually and / or automatically. In one case, settings 546 may be configured via a user interface 562.

[0054] The above disclosure allows executing software components (processes, applications, drivers, etc.) to become aware of a pending hibernation process (or any process that creates a snapshot so that the software components can enter a ready-to-resume state). This additional awareness capability allows the software components to enter a point suitable for restarting, referred to as the ready-to-resume state. This awareness capability overcomes problems with applications becoming frozen in any state. This awareness capability (and pre-hibernation activities that occur in response) allows the disclosure to overcome problems with changes to hardware and / or mechanical controls that occur for a device while it is in a hibernation state.

[0055] Users value the fact that, in a typical hibernation process, drivers are instructed to enter a sleep state. The disclosure approaches hibernation from the opposite direction, allowing system software components to notify the kernel that they are ready to be frozen after all pre-freeze initialization actions (pre-hibernation activities) have been performed. In one embodiment, a snapshot may be automatically created at system power-on or boot time, assuming no snapshot exists for a computing device. In one embodiment, a saved snapshot may be used to quickly recover from a failed state by powering on and resuming from the saved snapshot.

[0056] Additionally, in one embodiment, features may be implemented that enable frozen system software components to be unfrozen in a specified order, which may reduce user-perceived resume time and enable optimizations for parallel processing. Thus, embodiments of the disclosure capture details corresponding to the order in which system software components must be woken up. Furthermore, a snapshot may be performed during tidying operations (power-off operations may, but need not, occur) so that when a computing device is later resumed, this order can be followed. This minimizes wake-up time for a maximum amount of parallel work. In one embodiment, "out-of-box" snapshots may be created in a factory (or thereafter) for a particular device configuration.Snapshots ready for production can be generated manually, semi-manually or automatically to ensure that they are highly optimized in various considered embodiments.

[0057] In the foregoing description, particular embodiments have been described. However, one of ordinary skill in the art will appreciate that various modifications and changes may be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the description and drawings are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present teachings.

[0058] The benefits, advantages, and solutions to problems, and any part(s) that may produce or make more apparent any benefit, advantage, or solution, are not to be construed as crucial, necessary, or essential features or parts of any or all of the claims. The invention is defined solely by the appended claims, including any modifications made during the pendency of this application, and by all equivalents of those claims as published.

[0059] Furthermore, in this document, relative terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or act from another entity or act, without necessarily requiring or implying any actual such relationship or sequence between such entities or acts. The terms "comprises," "comprising," "has," or "has," "having," "includes," "including," "incorporates," "containing," or any other variation thereof are intended to represent non-exclusive inclusion, such that a process, method, article, or device that comprises, has, includes, or contains a number of parts not only includes those parts, but may include other parts not expressly enumerated or inherently belonging to such a process, method, article, or device. A part preceded by the phrase "comprises..."a", "has a...", "includes a...", "includes a...", does not exclude, without further limitation, the presence of additional identical parts in the process, method, article, or device that comprises, has, includes, or includes the part. The terms "a", "an", and "an" are defined as one or more unless expressly stated otherwise herein. The terms "substantial", "substantial", "approximately", "approximately", or any other version thereof are defined close to that understood by someone of ordinary skill in the art; and in one non-limiting embodiment, the term is defined as being within 10%, in another embodiment, within 5%, in another embodiment, within 1%, and in another embodiment, within 0.5%.The term "coupled" as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure "configured" in a particular manner is configured in at least that manner, but may also be configured in ways not enumerated.

[0060] It should be appreciated that some embodiments may consist of one or more generic or specialized processors (or "processing devices") such as microprocessors, digital signal processors, custom processors, and field programmable gate arrays (FPGAs), and special-purpose stored program instructions (including both software and firmware) controlling the one or more processors to, in conjunction with certain processor-free circuitry, implement some, most, or all of the functions of the method and / or apparatus described herein. Alternatively, some or all of the functions could be implemented by a state machine that does not have stored program instructions, or in one or more application-specific integrated circuits (ASICs) in which each function, or some combination of certain of the functions, is implemented as user-specific logic.Of course, a combination of the two approaches could be used.

[0061] Furthermore, an embodiment may be implemented as a computer-readable storage medium having computer-readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage media include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (read-only memory), a PROM (programmable read-only memory), an EPROM (erasable programmable read-only memory), an EEPROM (electrically erasable programmable read-only memory), and a flash memory.Furthermore, it is expected that someone of ordinary skill, perhaps not without considerable effort and stimulated by many design constraints, such as available time, current technology, and economic considerations, will readily be able to generate such program instructions and programs and integrated circuits (ICs) with minimal experimentation when guided by the concepts and principles disclosed herein.

Claims

[1] A method for hibernating and resuming system software, comprising: Before hibernating a computing device: notifying, by a processor of the computing device, system software components of an impending hibernation process; at least a portion of the system software components performs a pre-hibernation activity, by a processor, to place the system software component into a ready state for resumption; each system software component indicates, by a processor, that the system software component is ready for hibernation, wherein the hibernation process is not completed to create a snapshot of the system software components in the ready-for-resume state until each of the system software components has indicated that it is ready for hibernation; Creating, via the processor, the snapshot in a non-volatile memory; subsequently initializing, by the processor, a resume process from the created snapshot; and during the resumption process, controlled by the processor, varying a resumption time order for the system software components between a first and a second subset of the system software components, wherein the time order refers to a rate at which the system software components in the first subset of the system software components corresponding to a first end-user functionality are restored from the resume-ready state relative to the system software components in the second subset of the system software components corresponding to a second end-user functionality; wherein the resume ready state is a state in which resume initialization operations are performed with respect to external components of the computing device; and wherein, for at least one of the system software components, the ready state for resumption is a state that exists immediately before determining a variable associated with an external mechanical input component, whereby upon resumption, the at least one system software component checks the mechanical input to determine a value of the variable based on a current state of the mechanical input at resumption and before the variable is used or attempted to be used by that system software component. [2] The method of claim 1, further comprising: in response to receiving an indication from each of the system software components indicating that each of the system software components is ready for hibernation: completing the hibernation process creating the snapshot in the non-volatile memory, the snapshot saving state information for each of the system software components, the state information being for the ready state for resumption of the system software components. [3] The method of claim 1, wherein notifying the system software components is performed via an application programming interface (API), wherein displaying is performed via the application programming interface (API). [4] The method of claim 1, wherein the system software components run in a user space of an operating system, wherein the hibernation process is initiated and completed in a kernel space of the operating system; and wherein hibernation and resumption-specific communications between the kernel space and the user space occur via an application programming interface of the operating system. [5] Method according to claim 1, wherein the resume ready state is a state in which resume initialization operations are performed with respect to external components of the computing device; and wherein, for at least one of the system software components, the ready state for resumption is a state in which connections are checked for the presence or absence of an external hardware component on which the operation of that system software component depends or initialized, the hardware component being capable of being connected to and disconnected from the computing device during a period in which the computing device is in a powered-off state as a result of the hibernation process. [6] The method of claim 1, wherein the system software components receive the notification of the impending hibernation process while in a faulty state, wherein if the snapshot stored state information of the system software components in the faulty state, at least one faulty action would occur upon resuming, wherein when resuming the computing device from the created snapshot, the state information about the pre-fault readiness for resumption state of the system software components is used instead of the faulty state upon resuming. [7] The method of claim 1, further comprising: Detecting, during a startup process of the computing device, a lack of a generated snapshot; and automatically causing each system software component to provide resume readiness information for storage in a new snapshot while refraining from turning off the computing device or placing it in a power-saving state. [8] The method of claim 7, further comprising: automatically detecting an error or problematic condition in running software of the computing device; and in response to detecting the error or problematic state of the running software, reinitializing the computing device and the system software components from the new snapshot, wherein the computing device recovers from the error or problematic state in a relatively rapid manner using the new snapshot for recovery. [9] The method of claim 1, wherein the first subset of the system software components corresponds to a first core end-user functionality comprising telephony functionality, and the second subset of the system software components corresponds to a second non-core end-user functionality comprising a user interface or web browsing functionality. [10] The method of claim 1, wherein the first subset of the system software components corresponds to a first priority end-user functionality comprising end-user functionality that was in use at a time a fault was detected, and the second subset of the system software components corresponds to a second non-priority end-user functionality comprising end-user functionality that was not in use at the time the fault was detected. [11] The method of claim 1, wherein controllably varying the resumption time sequence comprises transmitting different thawing messages at different times to the first and second subsets of the system software components corresponding to the first and second end-user functionality. [12] Non-transitory computer-readable storage medium comprising: one or more computer-readable storage devices; Program instructions stored on at least one of the one or more storage devices that, when executed by a processor, perform a set of functions comprising: before hibernating a computing device, notifying system software components of an impending hibernation process; causing at least a portion of the system software components to perform a pre-hibernation activity to place that system software component into a ready state for resumption; causing each system software component to indicate that the system software component is ready for hibernation, wherein the hibernation process is not completed to create a snapshot of the system software components in the ready-for-resume state until each of the system software components has indicated that it is ready for hibernation; Creating the snapshot in a non-volatile memory of the computing device; subsequently initiating a resumption process from the created snapshot; and during the resumption process, controllably varying a resumption time sequence for the system software components between a first and a second subset of the system software components, wherein the time sequence relates to a speed at which the system software components in the first subset of the system software components corresponding to a first end-user functionality are restored from the resume-ready state relative to the system software components in the second subset of the system software components corresponding to a second end-user functionality; wherein the resume ready state is a state in which resume initialization operations are performed with respect to external components of the computing device; and wherein, for at least one of the system software components, the ready state for resumption is a state that exists immediately before determining a variable associated with an external mechanical input component, whereby upon resumption, the at least one system software component checks the mechanical input to determine a value of the variable based on a current state of the mechanical input at resumption and before the variable is used or attempted to be used by that system software component. [13] The non-transitory computer-readable storage medium of claim 12, wherein the set of functions further comprises: in response to receiving an indication from each of the system software components indicating that each of the system software components is ready for hibernation, completing the hibernation process, creating the snapshot in non-volatile memory, wherein the snapshot saves state information for each of the system software components, wherein the state information is for the ready state for resumption of the system software components, wherein the system software components run in a user space of an operating system, wherein the hibernation process is initiated and completed within a kernel space of the operating system, wherein hibernation and resumption-specific communications between the kernel space and the user space occur via an application programming interface (API) of the operating system. [14] The non-transitory computer-readable storage medium of claim 12, wherein the first subset of the system software components corresponds to a first end-user functionality comprising telephony functionality, and the second subset of the system software components corresponds to a second end-user functionality that is not core functionality and comprises one of user interface and web browsing functionality. [15] The non-transitory computer-readable storage medium of claim 12, wherein the first subset of the system software components corresponds to a first priority end-user functionality comprising end-user functionality that was in use at a time a fault was detected, and the second subset of the system software components corresponds to a second non-priority end-user functionality comprising end-user functionality that was not in use at the time the fault was detected. [16] A computer system for hibernating and resuming system software, comprising: one or more processors; one or more computer-readable memories; one or more non-volatile computer-readable storage devices; and Program instructions stored on at least one of the one or more computer-readable memories that, when executed by a processor, perform a set of functions comprising: before hibernating a computing device, notifying system software components of an impending hibernation process; causing at least a portion of the system software components to perform a pre-hibernation activity to place that system software component into a ready state for resumption; causing each system software component to indicate that that system software component is ready for hibernation, wherein the hibernation process is not completed to create a snapshot of the system software components in the ready-for-resume state until each of the system software components has indicated that it is ready for hibernation; Creating the snapshot in one or more non-volatile storage devices; subsequently initiating a resumption process from the created snapshot; and during the resumption process, controllably varying a resumption time sequence for the system software components between a first and a second subset of the system software components, wherein the time sequence relates to a speed at which the system software components in the first subset of the system software components corresponding to a first end-user functionality are restored from the resume-ready state relative to the system software components in the second subset of the system software components corresponding to a second end-user functionality; wherein, for at least one of the system software components, the ready state for resumption is a state that exists immediately before determining a variable associated with an external mechanical input component, whereby upon resumption, the at least one system software component checks the mechanical input to determine a value of the variable based on a current state of the mechanical input at resumption and before the variable is used or attempted to be used by that system software component. [17] The computer system of claim 16, wherein the system software components receive the notification of the impending hibernation process while in a faulty state, wherein if the snapshot stored state information of the system software components in the faulty state, at least one faulty action would occur upon resuming, wherein when resuming the computing device from the created snapshot, the state information about the pre-fault readiness for resumption state of the system software components is used instead of the faulty state upon resuming. [18] The computer system of claim 16, further comprising one of the following components: the first subset of the system software components corresponds to a first core end-user functionality comprising telephony functionality, and the second subset of the system software components corresponds to a second, non-core end-user functionality comprising either a user interface or web browsing functionality; and the first subset of the system software components corresponds to a first priority end-user functionality comprising end-user functionality that was in use at a time a fault was detected, and the second subset of the system software components corresponds to a second non-priority end-user functionality comprising end-user functionality that was not in use at the time the fault was detected.

Images