Live Update Orchestrator

Author:

Pasha Tatashin <pasha.tatashin@soleen.com>

Live Update is a specialized, kexec-based reboot process that allows arunning kernel to be updated from one version to another while preservingthe state of selected resources and keeping designated hardware devicesoperational. For these devices, DMA activity may continue throughout thekernel transition.

While the primary use case driving this work is supporting live updates ofthe Linux kernel when it is used as a hypervisor in cloud environments, theLUO framework itself is designed to be workload-agnostic. Live Updatefacilitates a full kernel version upgrade for any type of system.

For example, a non-hypervisor system running an in-memory cache likememcached with many gigabytes of data can use LUO. The userspace servicecan place its cache into a memfd, have its state preserved by LUO, andrestore it immediately after the kernel kexec.

Whether the system is running virtual machines, containers, ahigh-performance database, or networking services, LUO’s primary goal is toenable a full kernel update by preserving critical userspace state andkeeping essential devices operational.

The core of LUO is a mechanism that tracks the progress of a live update,along with a callback API that allows other kernel subsystems to participatein the process. Example subsystems that can hook into LUO include: kvm,iommu, interrupts, vfio, participating filesystems, and memory management.

LUO uses Kexec Handover to transfer memory state from the current kernel tothe next kernel. For more details seeKexec Handover Concepts.

LUO Sessions

LUO Sessions provide the core mechanism for grouping and managingstructfile * instances that need to be preserved across a kexec-based liveupdate. Each session acts as a named container for a set of file objects,allowing a userspace agent to manage the lifecycle of resources critical to aworkload.

Core Concepts:

  • Named Containers: Sessions are identified by a unique, user-provided name,which is used for both creation in the current kernel and retrieval in thenext kernel.

  • Userspace Interface: Session management is driven from userspace viaioctls on /dev/liveupdate.

  • Serialization: Session metadata is preserved using the KHO framework. Whena live update is triggered via kexec, an array ofstructluo_session_seris populated and placed in a preserved memory region. An FDT node is alsocreated, containing the count of sessions and the physical address of thisarray.

Session Lifecycle:

  1. Creation: A userspace agent callsluo_session_create() to create anew, empty session and receives a file descriptor for it.

  2. Serialization: When thereboot(LINUX_REBOOT_CMD_KEXEC) syscall ismade,luo_session_serialize() is called. It iterates through allactive sessions and writes their metadata into a memory area preservedby KHO.

  3. Deserialization (in new kernel): After kexec,luo_session_deserialize()runs, reading the serialized data and creating a list ofstructluo_session objects representing the preserved sessions.

  4. Retrieval: A userspace agent in the new kernel can then callluo_session_retrieve() with a session name to get a new filedescriptor and access the preserved state.

LUO Preserving File Descriptors

LUO provides the infrastructure to preserve specific, stateful filedescriptors across a kexec-based live update. The primary goal is to allowworkloads, such as virtual machines using vfio, memfd, or iommufd, toretain access to their essential resources without interruption.

The framework is built around a callback-based handler model and a well-defined lifecycle for each preserved file.

Handler Registration:Kernel modules responsible for a specific file type (e.g., memfd, vfio)register astructliveupdate_file_handler. This handler provides a set ofcallbacks that LUO invokes at different stages of the update process, mostnotably:

  • can_preserve(): A lightweight check to determine if the handler iscompatible with a given ‘structfile’.

  • preserve(): The heavyweight operation that saves the file’s state andreturns an opaque u64 handle. This is typically performed while theworkload is still active to minimize the downtime during theactual reboot transition.

  • unpreserve(): Cleans up any resources allocated by .preserve(), calledif the preservation process is aborted before the reboot (i.e. session isclosed).

  • freeze(): A final pre-reboot opportunity to prepare the state for kexec.We are already in reboot syscall, and therefore userspace cannot mutatethe file anymore.

  • unfreeze(): Undoes the actions of .freeze(), called if the live updateis aborted after the freeze phase.

  • retrieve(): Reconstructs the file in the new kernel from the preservedhandle.

  • finish(): Performs final check and cleanup in the new kernel. Aftersuccesul finish call, LUO gives up ownership to this file.

File Preservation Lifecycle happy path:

  1. Preserve (Normal Operation): A userspace agent preserves files one by onevia an ioctl. For each file,luo_preserve_file() finds a compatiblehandler, calls its .preserve() operation, and creates an internalstructluo_file to track the live state.

  2. Freeze (Pre-Reboot): Just before the kexec,luo_file_freeze() is called.It iterates through all preserved files, calls their respective .freeze()operation, and serializes their final metadata (compatible string, token,and data handle) into a contiguous memory block for KHO.

  3. Deserialize: After kexec,luo_file_deserialize() runs when session getsdeserialized (which is when /dev/liveupdate is first opened). It reads theserialized data from the KHO memory region and reconstructs the in-memorylist ofstructluo_file instances for the new kernel, linking them totheir corresponding handlers.

  4. Retrieve (New Kernel - Userspace Ready): The userspace agent can nowrestore file descriptors by providing a token.luo_retrieve_file()searches for the matching token, calls the handler’s .retrieve() op tore-create the ‘structfile’, and returns a new FD. Files can beretrieved in ANY order.

  5. Finish (New Kernel - Cleanup): Once a session retrival is complete,luo_file_finish() is called. It iterates through all files, invokes their.finish() operations for final cleanup, and releases all associated kernelresources.

File Preservation Lifecycle unhappy paths:

  1. Abort Before Reboot: If the userspace agent aborts the live updateprocess before calling reboot (e.g., by closing the session filedescriptor), the session’s release handler callsluo_file_unpreserve_files(). This invokes the .unpreserve() callback onall preserved files, ensuring all allocated resources are cleaned up andreturning the system to a clean state.

  2. Freeze Failure: During thereboot() syscall, if any handler’s .freeze()op fails, the .unfreeze() op is invoked on all previouslysuccessfulfreezes to roll back their state. Thereboot() syscall then returns anerror to userspace, canceling the live update.

  3. Finish Failure: In the new kernel, if a handler’s .finish() op fails,theluo_file_finish() operation is aborted. LUO retains ownership ofall files within that session, including those that were not yetprocessed. The userspace agent can attempt to call the finish operationagain later. If the issue cannot be resolved, these resources will be heldby LUO until the next live update cycle, at which point they will bediscarded.

Live Update Orchestrator ABI

This header defines the stable Application Binary Interface used by theLive Update Orchestrator to pass state from a pre-update kernel to apost-update kernel. The ABI is built upon the Kexec HandOver frameworkand uses a Flattened Device Tree to describe the preserved data.

This interface is a contract. Any modification to the FDT structure, nodeproperties, compatible strings, or the layout of the__packed serializationstructures defined here constitutes a breaking change. Such changes requireincrementing the version number in the relevant_COMPATIBLE string toprevent a new kernel from misinterpreting data from an old kernel.

Changes are allowed provided the compatibility version is incremented;however, backward/forward compatibility is only guaranteed for kernelssupporting the same ABI version.

FDT Structure Overview:

The entire LUO state is encapsulated within a single KHO entry named “LUO”.This entry contains an FDT with the following layout:

/ {    compatible = "luo-v1";    liveupdate-number = <...>;    luo-session {        compatible = "luo-session-v1";        luo-session-header = <phys_addr_of_session_header_ser>;    };};

Main LUO Node (/):

  • compatible: “luo-v1”Identifies the overall LUO ABI version.

  • liveupdate-number: u64A counter tracking the number of successful live updates performed.

Session Node (luo-session):

This node describes all preserved user-space sessions.

  • compatible: “luo-session-v1”Identifies the session ABI version.

  • luo-session-header: u64The physical address of astructluo_session_header_ser. This structureis the header for a contiguous block of memory containing an array ofstructluo_session_ser, one for each preserved session.

Serialization Structures:

The FDT properties point to memory regions containing arrays of simple,__packed structures. These structures contain the actual preserved state.

  • structluo_session_header_ser:Header for the session array. Contains the total page count of thepreserved memory block and the number ofstructluo_session_serentries that follow.

  • structluo_session_ser:Metadata for a single session, including its name and a physical pointerto another preserved memory block containing an array ofstructluo_file_ser for all files in that session.

  • structluo_file_ser:Metadata for a single preserved file. Contains thecompatible string tofind the correct handler in the new kernel, a user-providedtoken foridentification, and an opaquedata handle for the handler to use.

The following types of file descriptors can be preserved

Public API

structliveupdate_file_op_args

Arguments for file operation callbacks.

Definition:

struct liveupdate_file_op_args {    struct liveupdate_file_handler *handler;    bool retrieved;    struct file *file;    u64 serialized_data;    void *private_data;};

Members

handler

The file handler being called.

retrieved

The retrieve status for the ‘can_finish / finish’operation.

file

The file object. For retrieve: [OUT] The callback setsthis to the new file. For other ops: [IN] The caller setsthis to the file being operated on.

serialized_data

The opaque u64 handle, preserve/prepare/freeze may updatethis field.

private_data

Private data for the file used to hold runtime state thatis not preserved. Set by the handler’s .preserve()callback, and must be freed in the handler’s.unpreserve() callback.

Description

This structure bundles all parameters for the file operation callbacks.The ‘data’ and ‘file’ fields are used for both input and output.

structliveupdate_file_ops

Callbacks for live-updatable files.

Definition:

struct liveupdate_file_ops {    bool (*can_preserve)(struct liveupdate_file_handler *handler, struct file *file);    int (*preserve)(struct liveupdate_file_op_args *args);    void (*unpreserve)(struct liveupdate_file_op_args *args);    int (*freeze)(struct liveupdate_file_op_args *args);    void (*unfreeze)(struct liveupdate_file_op_args *args);    int (*retrieve)(struct liveupdate_file_op_args *args);    bool (*can_finish)(struct liveupdate_file_op_args *args);    void (*finish)(struct liveupdate_file_op_args *args);    struct module *owner;};

Members

can_preserve

Required. Lightweight check to see if this handler iscompatible with the given file.

preserve

Required. Performs state-saving for the file.

unpreserve

Required. Cleans up any resources allocated bypreserve.

freeze

Optional. Final actions just before kernel transition.

unfreeze

Optional. Undo freeze operations.

retrieve

Required. Restores the file in the new kernel.

can_finish

Optional. Check if this FD can finish, i.e. all restorationpre-requirements for this FD are satisfied. Called prior tofinish, in order to do successful finish calls for allresources in the session.

finish

Required. Final cleanup in the new kernel.

owner

Module reference

Description

All operations (except can_preserve) receive a pointer to a‘structliveupdate_file_op_args’ containing the necessary context.

structliveupdate_file_handler

Represents a handler for a live-updatable file type.

Definition:

struct liveupdate_file_handler {    const struct liveupdate_file_ops *ops;    const char compatible[LIVEUPDATE_HNDL_COMPAT_LENGTH];};

Members

ops

Callback functions

compatible

The compatibility string (e.g., “memfd-v1”, “vfiofd-v1”)that uniquely identifies the file type this handlersupports. This is matched against the compatible stringassociated with individualstructfile instances.

Description

Modules that want to support live update for specific file types shouldregister an instance of this structure. LUO uses this registration todetermine if a given file can be preserved and to find the appropriateoperations to manage its state across the update.

structluo_file_ser

Represents the serialized preserves files.

Definition:

struct luo_file_ser {    char compatible[LIVEUPDATE_HNDL_COMPAT_LENGTH];    u64 data;    u64 token;};

Members

compatible

File handler compatible string.

data

Private data

token

User provided token for this file

Description

If this structure is modified, LUO_SESSION_COMPATIBLE must be updated.

structluo_file_set_ser

Represents the serialized metadata for file set

Definition:

struct luo_file_set_ser {    u64 files;    u64 count;};

Members

files

The physical address of a contiguous memory block that holdsthe serialized state of files (array of luo_file_ser) in this fileset.

count

The total number of files that were part of this session duringserialization. Used for iteration and validation duringrestoration.

structluo_session_header_ser

Header for the serialized session data block.

Definition:

struct luo_session_header_ser {    u64 count;};

Members

count

The number ofstructluo_session_ser entries that immediatelyfollow this header in the memory block.

Description

This structure is located at the beginning of a contiguous block ofphysical memory preserved across the kexec. It provides the necessarymetadata to interpret the array of session entries that follow.

If this structure is modified,LUO_FDT_SESSION_COMPATIBLE must be updated.

structluo_session_ser

Represents the serialized metadata for a LUO session.

Definition:

struct luo_session_ser {    char name[LIVEUPDATE_SESSION_NAME_LENGTH];    struct luo_file_set_ser file_set_ser;};

Members

name

The unique name of the session, provided by the userspace atthe time of session creation.

file_set_ser

Serialized files belonging to this session,

Description

This structure is used to package session-specific metadata for transferbetween kernels via Kexec Handover. An array of these structures (one persession) is created and passed to the new kernel, allowing it to reconstructthe session context.

If this structure is modified,LUO_FDT_SESSION_COMPATIBLE must be updated.

Internal API

intliveupdate_reboot(void)

Kernel reboot notifier for live update final serialization.

Parameters

void

no arguments

Description

This function is invoked directly from thereboot() syscall pathwayif kexec is in progress.

If any callback fails, this function aborts KHO, undoes thefreeze()callbacks, and returns an error.

boolliveupdate_enabled(void)

Check if the live update feature is enabled.

Parameters

void

no arguments

Description

This function returns the state of the live update feature flag, whichcan be controlled via theliveupdate kernel command-line parameter.

return true if live update is enabled, false otherwise.

structluo_session_header

Header struct for managing LUO sessions.

Definition:

struct luo_session_header {    long count;    struct list_head list;    struct rw_semaphore rwsem;    struct luo_session_header_ser *header_ser;    struct luo_session_ser *ser;    bool active;};

Members

count

The number of sessions currently tracked in thelist.

list

The head of the linked list ofstructluo_session instances.

rwsem

A read-write semaphore providing synchronized access to thesession list and other fields in this structure.

header_ser

The header data of serialization array.

ser

The serialized session data (an array ofstructluo_session_ser).

active

Set to true when first initialized. If previous kernel did notsend session data, active stays false for incoming.

structluo_session_global

Global container for managing LUO sessions.

Definition:

struct luo_session_global {    struct luo_session_header incoming;    struct luo_session_header outgoing;};

Members

incoming

The sessions passed from the previous kernel.

outgoing

The sessions that are going to be passed to the next kernel.

boolluo_session_quiesce(void)

Ensure no active sessions exist and lock session lists.

Parameters

void

no arguments

Description

Acquires exclusive write locks on both incoming and outgoing session lists.It then validates no sessions exist in either list.

This mechanism is used during file handler un/registration to ensure that nosessions are currently using the handler, and no new sessions can be createdwhile un/registration is in progress.

This prevents registering new handlers while sessions are active orwhile deserialization is in progress.

Return

true - System is quiescent (0 sessions) and locked.false - Active sessions exist. The locks are released internally.

voidluo_session_resume(void)

Unlock session lists and resume normal activity.

Parameters

void

no arguments

Description

Releases the exclusive locks acquired by a successful call toluo_session_quiesce().

structluo_file

Represents a single preserved file instance.

Definition:

struct luo_file {    struct liveupdate_file_handler *fh;    struct file *file;    u64 serialized_data;    void *private_data;    bool retrieved;    struct mutex mutex;    struct list_head list;    u64 token;};

Members

fh

Pointer to thestructliveupdate_file_handler that managesthis type of file.

file

Pointer to the kernel’sstructfile that is being preserved.This is NULL in the new kernel until the file is successfullyretrieved.

serialized_data

The opaque u64 handle to the serialized state of the file.This handle is passed back to the handler’s .freeze(),.retrieve(), and .finish() callbacks, allowing it to trackand update its serialized state across phases.

private_data

Pointer to the private data for the file used to hold runtimestate that is not preserved. Set by the handler’s .preserve()callback, and must be freed in the handler’s .unpreserve()callback.

retrieved

A flag indicating whether a user/kernel in the new kernel hassuccessfully calledretrieve() on this file. This preventsmultiple retrieval attempts.

mutex

A mutex that protects the fields of this specific instance(e.g.,retrieved,file), ensuring that operations likeretrieving or finishing a file are atomic.

list

The list_head linking this instance into its parentfile_set’s list of preserved files.

token

The user-provided unique token used to identify this file.

Description

This structure is the core in-kernel representation of a single file beingmanaged through a live update. An instance is created byluo_preserve_file()to link a ‘structfile’ to its corresponding handler, a user-provided token,and the serialized state handle returned by the handler’s .preserve()operation.

These instances are tracked in a per-file_set list. Theserialized_datafield, which holds a handle to the file’s serialized state, may be updatedduring the .freeze() callback before being serialized for the next kernel.After reboot, these structures are recreated byluo_file_deserialize() andare finally cleaned up byluo_file_finish().

intluo_preserve_file(structluo_file_set*file_set,u64token,intfd)

Initiate the preservation of a file descriptor.

Parameters

structluo_file_set*file_set

The file_set to which the preserved file will be added.

u64token

A unique, user-provided identifier for the file.

intfd

The file descriptor to be preserved.

Description

This function orchestrates the first phase of preserving a file. Upon entry,it takes a reference to the ‘structfile’ viafget(), effectively making LUOa co-owner of the file. This reference is held until the file is eitherunpreserved or successfully finished in the next kernel, preventing the filefrom being prematurely destroyed.

This function orchestrates the first phase of preserving a file. It performsthe following steps:

  1. Validates that thetoken is not already in use within the file_set.

  2. Ensures the file_set’s memory for files serialization is allocated(allocates if needed).

  3. Iterates through registered handlers, callingcan_preserve() to find onecompatible with the givenfd.

  4. Calls the handler’s .preserve() operation, which saves the file’s stateand returns an opaque private data handle.

  5. Adds the new instance to the file_set’s internal list.

On success, LUO takes a reference to the ‘structfile’ and considers itunder its management until it is unpreserved or finished.

In case of any failure, all intermediate allocations (file reference, memoryfor the ‘luo_file’ struct, etc.) are cleaned up before returning an error.

Context

Can be called from an ioctl handler during normal system operation.

Return

0 on success. Returns a negative errno on failure:-EEXIST if the token is already used.-EBADF if the file descriptor is invalid.-ENOSPC if the file_set is full.-ENOENT if no compatible handler is found.-ENOMEM on memory allocation failure.Other erros might be returned by .preserve().

voidluo_file_unpreserve_files(structluo_file_set*file_set)

Unpreserves all files from a file_set.

Parameters

structluo_file_set*file_set

The files to be cleaned up.

Description

This function serves as the primary cleanup path for a file_set. It isinvoked when the userspace agent closes the file_set’s file descriptor.

For each file, it performs the following cleanup actions:
  1. Calls the handler’s .unpreserve() callback to allow the handler torelease any resources it allocated.

  2. Removes the file from the file_set’s internal tracking list.

  3. Releases the reference to the ‘structfile’ that was taken byluo_preserve_file() viafput(), returning ownership.

  4. Frees the memory associated with the internal ‘structluo_file’.

After all individual files are unpreserved, it frees the contiguous memoryblock that was allocated to hold their serialization data.

intluo_file_freeze(structluo_file_set*file_set,structluo_file_set_ser*file_set_ser)

Freezes all preserved files and serializes their metadata.

Parameters

structluo_file_set*file_set

The file_set whose files are to be frozen.

structluo_file_set_ser*file_set_ser

Where to put the serialized file_set.

Description

This function is called from thereboot() syscall path, just before thekernel transitions to the new image via kexec. Its purpose is to perform thefinal preparation and serialization of all preserved files in the file_set.

It iterates through each preserved file in FIFO order (the order ofpreservation) and performs two main actions:

  1. Freezes the File: It calls the handler’s .freeze() callback for eachfile. This gives the handler a final opportunity to quiesce the device orprepare its state for the upcoming reboot. The handler may update itsprivate data handle during this step.

  2. Serializes Metadata: After a successful freeze, it copies the final filemetadata—the handler’s compatible string, the user token, and the finalprivate data handle—into the pre-allocated contiguous memory buffer(file_set->files) that will be handed over to the next kernel via KHO.

Error Handling (Rollback):This function is atomic. If any handler’s .freeze() operation fails, theentire live update is aborted. The__luo_file_unfreeze() helper isimmediately called to invoke the .unfreeze() op on all files that weresuccessfully frozen before the point of failure, rolling them back to arunning state. The function then returns an error, causing thereboot()syscall to fail.

Context

Called only from theliveupdate_reboot() path.

Return

0 on success, or a negative errno on failure.

voidluo_file_unfreeze(structluo_file_set*file_set,structluo_file_set_ser*file_set_ser)

Unfreezes all files in a file_set and clear serialization

Parameters

structluo_file_set*file_set

The file_set whose files are to be unfrozen.

structluo_file_set_ser*file_set_ser

Serialized file_set.

Description

This function rolls back the state of all files in a file_set after thefreeze phase has begun but must be aborted. It is the counterpart toluo_file_freeze().

It invokes the__luo_file_unfreeze() helper with a NULL argument, whichsignals the helper to iterate through all files in the file_set and calltheir respective .unfreeze() handler callbacks.

Context

This is called when the live update is aborted duringthereboot() syscall, afterluo_file_freeze() has been called.

intluo_retrieve_file(structluo_file_set*file_set,u64token,structfile**filep)

Restores a preserved file from a file_set by its token.

Parameters

structluo_file_set*file_set

The file_set from which to retrieve the file.

u64token

The unique token identifying the file to be restored.

structfile**filep

Output parameter; on success, this is populated with a pointerto the newly retrieved ‘structfile’.

Description

This function is the primary mechanism for recreating a file in the newkernel after a live update. It searches the file_set’s list of deserializedfiles for an entry matching the providedtoken.

The operation is idempotent: if a file has already been successfullyretrieved, this function will simply return a pointer to the existing‘structfile’ and report success without re-executing the retrieveoperation. This is handled by checking the ‘retrieved’ flag under a lock.

File retrieval can happen in any order; it is not bound by the order ofpreservation.

Context

Can be called from an ioctl or other in-kernel code in the newkernel.

Return

0 on success. Returns a negative errno on failure:-ENOENT if no file with the matching token is found.Any error code returned by the handler’s .retrieve() op.

intluo_file_finish(structluo_file_set*file_set)

Completes the lifecycle for all files in a file_set.

Parameters

structluo_file_set*file_set

The file_set to be finalized.

Description

This function orchestrates the final teardown of a live update file_set inthe new kernel. It should be called after all necessary files have beenretrieved and the userspace agent is ready to release the preserved state.

The function iterates through all tracked files. For each file, it performsthe following sequence of cleanup actions:

  1. If file is not yet retrieved, retrieves it, and callscan_finish() onevery file in the file_set. If all can_finish return true, continue tofinish.

  2. Calls the handler’s .finish() callback (via luo_file_finish_one) toallow for final resource cleanup within the handler.

  3. Releases LUO’s ownership reference on the ‘structfile’ viafput(). Thisis the counterpart to theget_file() call inluo_retrieve_file().

  4. Removes the ‘structluo_file’ from the file_set’s internal list.

  5. Frees the memory for the ‘structluo_file’ instance itself.

After successfully finishing all individual files, it frees thecontiguous memory block that was used to transfer the serialized metadatafrom the previous kernel.

Error Handling (Atomic Failure):This operation is atomic. If any handler’s .can_finish() op fails, the entirefunction aborts immediately and returns an error.

Context

Can be called from an ioctl handler in the new kernel.

Return

0 on success, or a negative errno on failure.

intluo_file_deserialize(structluo_file_set*file_set,structluo_file_set_ser*file_set_ser)

Reconstructs the list of preserved files in the new kernel.

Parameters

structluo_file_set*file_set

The incoming file_set to fill with deserialized data.

structluo_file_set_ser*file_set_ser

Serialized KHO file_set data from the previous kernel.

Description

This function is called during the early boot process of the new kernel. Ittakes the raw, contiguous memory block of ‘structluo_file_ser’ entries,provided by the previous kernel, and transforms it back into a live,in-memory linked list of ‘structluo_file’ instances.

For each serialized entry, it performs the following steps:
  1. Reads the ‘compatible’ string.

  2. Searches the global list of registered file handlers for one thatmatches the compatible string.

  3. Allocates a new ‘structluo_file’.

  4. Populates the new structure with the deserialized data (token, privatedata handle) and links it to the found handler. The ‘file’ pointer isinitialized to NULL, as the file has not been retrieved yet.

  5. Adds the new ‘structluo_file’ to the file_set’s files_list.

This prepares the file_set for userspace, which can later callluo_retrieve_file() to restore the actual file descriptors.

Context

Called from session deserialization.

intliveupdate_register_file_handler(structliveupdate_file_handler*fh)

Register a file handler with LUO.

Parameters

structliveupdate_file_handler*fh

Pointer to a caller-allocatedstructliveupdate_file_handler.The caller must initialize this structure, including a unique‘compatible’ string and a valid ‘fh’ callbacks. This function adds thehandler to the global list of supported file handlers.

Context

Typically called during module initialization for file types thatsupport live update preservation.

Return

0 on success. Negative errno on failure.

intliveupdate_unregister_file_handler(structliveupdate_file_handler*fh)

Unregister a liveupdate file handler

Parameters

structliveupdate_file_handler*fh

The file handler to unregister

Description

Unregisters the file handler from the liveupdate core. This functionreverses the operations ofliveupdate_register_file_handler().

It ensures safe removal by checking that:No live update session is currently in progress.

If the unregistration fails, the internal test state is reverted.

Return

0 Success. -EOPNOTSUPP when live update is not enabled. -EBUSY A liveupdate is in progress, can’t quiesce live update.

See Also