WO2019180376A1 - Procédé et système pour créer une image d'une application - Google Patents

Procédé et système pour créer une image d'une application Download PDF

Info

Publication number
WO2019180376A1
WO2019180376A1 PCT/FR2019/050632 FR2019050632W WO2019180376A1 WO 2019180376 A1 WO2019180376 A1 WO 2019180376A1 FR 2019050632 W FR2019050632 W FR 2019050632W WO 2019180376 A1 WO2019180376 A1 WO 2019180376A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
image
software libraries
code
compiling
Prior art date
Application number
PCT/FR2019/050632
Other languages
English (en)
Inventor
Ruan HE
Maxime COMPASTIE
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2019180376A1 publication Critical patent/WO2019180376A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/76—Adapting program code to run in a different environment; Porting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions

Definitions

  • the invention relates to the general field of using an application. It relates more particularly to the construction of an image of an application.
  • the solutions running in a virtual machine are known, the latter running on a physical machine, for example a remote server.
  • a solution is also known to install and execute (that is, to "deploy") an application in an application container hosted in a physical machine.
  • the application container includes the application's binary code and software libraries. This solution optimizes the system resources compared to the installation of a virtual machine since the container does not have a complete operating system.
  • the application container is self-contained and self-sufficient to run based on an operating system running on the physical machine.
  • a container executed by a machine, is a set of processes isolated from the rest of the other processes running on the same physical or virtual machine.
  • An application container runs from an image that provides the files needed to support its processes.
  • the container of an application must be compatible with the operating system of the physical or virtual machine that executes it, that is, the software libraries included in the application image must be compatible with the operating system of the physical or virtual machine.
  • a method of creating an image of an application consists of compiling the binary code of the application and all the software libraries required by the application so that it can be executed on several operating systems .
  • the code and the software libraries are compiled together.
  • the result of the compilation is an image of the application executable on several operating systems.
  • the image created by the generalist method is portable in that it can be executed on the various operating systems mentioned above.
  • this generalist method consumes system resources. Indeed, when the image is executed on a machine With a given operating system, the software libraries corresponding to other operating systems are not used and consume memory.
  • the image of the created application of type "specific language” consumes less system resources than a created image of generalist type. However, the portability of the created image of type "specific language” is not assured.
  • the invention is directed to a method for creating an image of an application, this image being capable of being used to execute a container of this application on a hypervisor.
  • the method comprises the steps of:
  • the invention is a system for creating an image of an application, this image being able to be used to run a container of this application on a hypervisor.
  • This system comprises:
  • a module configured to determine a set of software libraries required by a set of system calls used by the application and identified in the first object
  • a module for obtaining a second object obtained by compiling said software libraries for a given operating system
  • the set of software libraries required by all the system calls used by the application comprises only the software libraries that comprise the routines corresponding to these calls.
  • the invention makes it possible to optimize the system resources in comparison with a method of the generalist type, because the second object is obtained by compiling the software libraries required by the application, and only these.
  • the first object Since the first object is independent of an operating system, it can be reassembled with another second object to create an image of the application that is compatible with another operating system.
  • the first object can be in an interpreted language such as Java or Python.
  • the created image can later be deployed to an application container.
  • a set of software libraries required by the application refers to all the software libraries required by the application.
  • the first and second objects obtained by compilation are object files in a target language, for example in object files conforming to a machine language such as an assembly language.
  • an object file is an intermediate file obtained during a compilation process. This file contains data necessary for linking. Thus, this object file is not executable directly.
  • the first and second objects are binary.
  • the set of software libraries required by the application is determined from the first compiled object.
  • the code of the application is not disclosed for the implementation of the method.
  • the determination, according to the invention, of all the software libraries is an automatic determination.
  • the method according to the invention further comprises a step of calculating a signature of the first object and a signature of the second object.
  • the image created is then characterized by a pair of signatures, namely the signature of the first object and the signature of the second object, which makes it possible to detect an image in accordance with the present invention.
  • the step of determining the set of software libraries comprises searching, in the first object, a first sequence corresponding to a system call, the system call used by the application being identified by a second sequence related to the first sequence.
  • the first sequence and the second sequence related to the first sequence conform to the language of the first object obtained by compilation.
  • the first sequence and the second sequence related to the first sequence are binary instructions conforming to an external architecture of the processor (ISA for "Instruction Set Architecture”).
  • system calls used by the application are of the System Call List (Portable Operating System Interface) type IEEE 1003 contained in a list.
  • the second sequence identifies a system call from this list.
  • a dictionary associates an ABI system call (for "Application Binary Interface") with software libraries implementing them. The software library or libraries required by each system call are thus identified.
  • ABI system call for "Application Binary Interface”
  • dependencies of a software library identified with one or other software libraries are determined and this or these libraries are added to a list of all the software libraries required by the application.
  • the invention also relates to an image of an application, this image being capable of being used to execute a container of this application on a hypervisor. It involves :
  • An object corresponding to a first object obtained by compiling the code of the application, produced during an assembly of the first object with a second object, system call memory addresses identified in the first object being edited at the time of the first object; assembling to point to corresponding routines in the second object, said first object being independent of an operating system; and
  • the second object obtained by compiling a set of software libraries required by a set of system calls used by the application for a given operating system.
  • the image of the application according to the invention can be used to execute a container of this application.
  • the container can run on a hypervisor, which runs on hardware resources of a physical machine.
  • the hypervisor allows the application container to communicate with the hardware resources of the physical machine.
  • Such an architecture application container / hypervisor / hardware resources
  • unikernel is known in English as "unikernel”.
  • the method of the invention makes it possible to create an image of an application according to the invention.
  • an application container is executed from the image of an application according to the invention.
  • the container is installed on a hypervisor.
  • the invention also relates to a first computer program on a recording medium, this program being capable of being implemented in a computer or in a device included in the system according to the invention, this program comprising adapted instructions implementing a method for creating an image of an application as described above.
  • the invention also relates to a second computer program on a recording medium, this program being capable of being implemented in a computer or in a device included in the system according to the invention, this program comprising adapted instructions. implementing a method for executing an image according to the invention.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any form what other form is desirable.
  • the invention also relates to computer readable information or recording media, and including instructions of the computer programs as mentioned above.
  • the information or recording media may be any entity or device capable of storing the programs.
  • the media may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a disk. hard, or a flash memory.
  • the information or recording media may be transmissible media such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.
  • the programs according to the invention may in particular be downloaded on an Internet-type network.
  • each information or recording medium may be an integrated circuit in which one of the programs is embedded, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 is a flowchart representing the steps of a method for creating an image of an application, according to a particular embodiment
  • FIG. 2 illustrates the functional architecture of a system for creating an image according to a particular embodiment
  • FIG. 3 illustrates the hardware architecture of a device of the system for creating an image according to a particular embodiment
  • FIG. 4 represents an image of an application created by the proposed method according to a particular embodiment
  • FIG. 5 shows the software architecture for executing an image according to the invention, according to a particular embodiment.
  • FIG. 1 represents a flowchart representing steps of a method for creating an IMG image of an application, according to a particular embodiment.
  • a CODE_APP source code of the application has been compiled during a step T10 which precedes the implementation of the steps of the proposed creation process.
  • a SYS system which implements the method of creating an image obtains a first object 01 obtained by compiling (T10) the source code of the application.
  • the first object 01 obtained by compilation is an object file in a target language, for example an object file conforming to a machine language such as an assembly language.
  • an object file is an intermediate file obtained during a compilation process. This file contains data necessary for linking. Thus, this object file is not executable directly.
  • the first object 01 is a binary object.
  • this first object 01 is of type blob (Binary Large OBject).
  • the obtaining (E10) of the first object 01 can consist in the reception of the object 01, by a means of communication of the system or by a reading from a mobile recording medium on which the first object 01 has been checked in.
  • the SYS system determines the set of LIB software libraries required by the application from all the system calls used by the application and identified in the first object 01.
  • the SYS system looks in the first bit object 01 for all the different system calls used to form all the system calls. The SYS system then identifies the software library or libraries required by each system call by ignoring any duplicate software libraries, for example corresponding to two separate system calls of the same library, and thus obtains a list of all the software libraries. LIB required by the application.
  • the search for system calls used by the application is based on a search for a first sequence, characteristic of a system call.
  • a second sequence related to the first sequence then identifies the system call required by the application.
  • the first and second sequences are binary sequences.
  • the first bit sequence is characteristic of a system call.
  • a specific Posix type system call has two parts: an identical first part for all system calls, and a second part that characterizes this specific system call.
  • the first identical part is the first binary sequence sought, while the second part represents the second sequence connected to the first sequence.
  • the second parts are for example contained or referenced in a list, thereby identifying a system call from this list.
  • a dictionary associates an ABI system call (for "Application Binary Interface") with software libraries implementing them.
  • the SYS system thus identifies the software library or libraries required by each system call.
  • dependencies of a software library identified with one or other software libraries are determined and this or these libraries are added to the list of software libraries required by the application.
  • the SYS system obtains a second object 02 generated by compiling the set of LIB software libraries determined in step E20 for a given operating system.
  • This second object 02 is thus customized for this operating system.
  • This second object 02 is also an object file.
  • the set of LIB software libraries can be compiled by the SYS system during the step E30 itself, the result of the compilation is the second object 02.
  • the second object 02 is a binary object.
  • this second object 02 is of the blob type.
  • a signature SIG1, SIG2 is calculated for each of the objects 01 and 02 during a step E40.
  • signature is meant a footprint calculated on all or part of an object O and characterizing the latter.
  • the signature SIG1 is calculated on a part of the object 01 which is not modified during the assembly step E50, described later.
  • the signature of the object 01 corresponds to the list of all the system calls identified in this object 01.
  • the signature of the object 02 corresponds to the list of system calls that it implements, as well as the operating system whose support is targeted.
  • the image created according to the proposed creation method is characterized by a pair of the two signatures (SIG1, SIG2). corresponding to the signatures of the two objects 01 and 02.
  • the first object 01 and the second object 02 are assembled ("link" in English) to create the IMG image of the application.
  • the memory addresses of the system calls identified in the first object 01 are edited to point to the corresponding routines in the second object 02.
  • this edition produces an object O'I corresponding to the first object 01.
  • the image created IMG can be executed, in a step that follows the creation process, to obtain a container of the application.
  • the application can thus be executed on a physical or virtual machine compatible with the given operating system used to obtain the second object 02.
  • Multiple instances of the IMG image can be generated to run the application on different physical or virtual machines compatible with the given operating system used to obtain the second object 02.
  • the creation method has input only CODE_APP source code.
  • the system SYS compiles the source code CODE_APP during the step E10, the result of the compilation representing the first object 01.
  • the step E30 for generating the second object 02 by compiling the LIB software libraries is performed by a device that is not part of the SYS system.
  • the SYS system receives, during the step E30, the second object 02.
  • This method of creating an image finds an advantageous application in the context of the construction of "unikernel" type system images, in which an executable of a application includes all operating system routines sufficient to run in a system virtualization environment. Thanks to the proposed creation method, the executable of the application includes only the operating system routines strictly necessary for its execution.
  • FIG. 2 represents the functional architecture of a SYS system for creating an IMG image of an application, in accordance with one embodiment of the invention.
  • the SYS system comprises:
  • a module MODJ.IB configured to determine a set of libraries LIB software required by the application from a set of system calls used by the application and identified in the first object 01;
  • the first object 01 and / or the second object 02 are object files.
  • the module M0D_01 for obtaining a first object 01 may receive as input the first object 01 or the CODE_APP code of the application.
  • the module M0D_01 outputs the first object 01.
  • the module MOD_LIB receives as input the first object 01.
  • the module MOD_LIB generates as output all LIB software libraries required by the application, as described above.
  • the module M0D_02 for obtaining a second object 02 receives as input the set LIB of the software libraries required by the application, for a given operating system, and outputs the second object 02.
  • the assembly module MOD_LINK of the objects 01 and 02 requires as inputs the first object 01 and the second object 02. At the output, it provides the IMG image of the application by linking, as described above.
  • the modules M0D_01, M0D_02, MOD_LIB and MODJ.INK can be implemented by various devices of the SYS system.
  • each device of the SYS system has the architecture of a computer, as illustrated in FIG. 3. It notably comprises a processor 7, a random access memory 8, a memory 9, a non flash memory in a particular embodiment of the invention, as well as communication means 11. Such means are known per se and are not described in more detail here.
  • the read-only memory 9 of a device included in the system SYS for creating an image according to the invention constitutes a recording medium in accordance with the invention, readable by the processor 7 and on which is recorded here a program of Prog computer according to the invention.
  • the memory 10 of a device included in the SYS system makes it possible to record variables used for the execution of the steps of the invention, such as the CODE_APP code of the application, a list of the system calls used by the application. , a list of Posix System Call type system calls, a temporary or definitive search result for system calls, etc.
  • the Prog computer program defines functional and software modules here, configured to allow a SYS system to create an IMG image of an application. These functional modules rely on and / or control the hardware elements 7-11 of a device of the SYS system mentioned above.
  • FIG. 4 represents an IMG image of an application, the IMG image being obtained by executing the proposed creation method.
  • the IMG image is a program executable by a physical or virtual machine.
  • the IMG image comprises:
  • the second object 02 obtained by compiling (E30) a set of LIB software libraries required by the application.
  • the IMG image according to the invention is characterized by a pair of signatures SIG1 and SIG2 corresponding to the signatures of the first object O1 and the second object O2.
  • FIG. 5 illustrates the software architecture allowing the execution of an IMG image according to the invention, according to one embodiment of the invention.
  • a C_APP application container is executed from the IMG image of the application, and installed on a HYP hypervisor of the ORD machine.
  • the HYP hypervisor is implemented over the PHY hardware infrastructure of the ORD machine.
  • the IMG image is a "unikernel” type image and the C_APP application container is a virtual machine running on the PHY hardware infrastructure of the ORD machine.
  • the ORD physical machine has the architecture of a computer, similar to the architecture shown in Figure 3.
  • This software architecture may for example be used in a mobile 5 th generation communication network (5G) wherein virtualized network functions are implemented to ensure both portability and performance of the virtualized network function.
  • 5G mobile 5 th generation communication network
  • the invention is also directed to a Proglmg computer program which defines functional and software modules here configured to enable a physical ORD machine to execute an IMG image according to the invention.
  • These functional modules rely on and / or control the hardware elements 7-11 of the ORD machine: a processor 7, a random access memory 8, a read-only memory 9, a non-volatile flash memory 10 in a particular embodiment of the invention. invention, as well as communication means 11.
  • the read-only memory 9 of the ORD machine constitutes a recording medium in accordance with the invention, readable by the processor 7 of the ORD machine and on which is recorded here a computer program Proglmg according to the invention, allowing the execution of the IMG image shown in Figure 4.
  • the memory 10 of the machine ORD makes it possible to record variables used for the execution of the steps of execution of the IMG image according to the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Image Processing (AREA)

Abstract

Procédé et système de création d'une image d'une application, cette image étant susceptible d'être utilisée pour exécuter un conteneur de cette application sur un hyperviseur, le procédé comportant les étapes suivantes : - obtention (E10) d'un premier objet (O1) obtenu par compilation (E10, T10) du code (CODE_APP) de l'application, ledit premier objet étant indépendant d'un système d'exploitation; - détermination (E20) d'un ensemble de bibliothèques logicielles (LIB) requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet (O1); - obtention (E30) d'un deuxième objet (O2) obtenu par compilation (E30) desdites bibliothèques logicielles (LIB) pour un système d'exploitation personnalisé donné; et - assemblage (E50) desdits objets pour créer ladite image (IMG) de l'application.

Description

Procédé et système pour créer une image d'une application
Arrière-plan de l'invention
L'invention se rapporte au domaine général de l'utilisation d'une application. Elle concerne plus particulièrement la construction d'une image d'une application.
Parmi les solutions existantes permettant l'utilisation d'une application, on connaît les solutions s'exécutant dans une machine virtuelle, cette dernière s'exécutant sur une machine physique, par exemple un serveur distant.
Ces solutions présentent l'inconvénient de consommer des ressources (mémoire, capacité de calcul, ...) importantes au niveau de la machine physique. En effet, l'utilisation d'une machine virtuelle nécessite en plus des ressources nécessaires à l'exécution de l'application elle- même, des ressources pour l'exécution d'un système d'exploitation complet, pour la gestion des bibliothèques logicielles et éventuellement pour l'ordonnancement (scheduling) des applications.
On connaît également une solution consistant à installer et à exécuter (autrement dit à « déployer ») une application dans un conteneur d'application hébergé dans une machine physique. Le conteneur d'application comporte le code binaire de l'application et des bibliothèques logicielles. Cette solution permet d'optimiser les ressources système par rapport à l'installation d'une machine virtuelle puisque le conteneur ne comporte pas un système d'exploitation complet. Le conteneur d'application est autonome et auto-suffisant pour s'exécuter en s'appuyant sur un système d'exploitation s'exécutant sur la machine physique.
On rappelle qu'un conteneur, exécuté par une machine, est un ensemble de processus isolés du reste des autres processus s'exécutant sur une même machine physique ou virtuelle. Un conteneur d'application s'exécute à partir d'une image qui fournit les fichiers nécessaires à la prise en charge de ses processus.
Le conteneur d'une application doit être compatible avec le système d'exploitation de la machine physique ou virtuelle qui l'exécute, autrement dit, les bibliothèques logicielles comprises dans l'image de l'application doivent être compatibles avec le système d'exploitation de la machine physique ou virtuelle.
Une méthode de création d'une image d'une application, de type généraliste, consiste à compiler le code binaire de l'application et toutes les bibliothèques logicielles requises par l'application pour qu'elle puisse être exécutée sur plusieurs systèmes d'exploitation. Le code et les bibliothèques logicielles sont compilés ensemble. Le résultat de la compilation est une image de l'application exécutable sur plusieurs systèmes d'exploitation.
L'image créée par la méthode généraliste est portable en ce qu'elle peut être exécutée sur les différents systèmes d'exploitation précités. Cependant, cette méthode généraliste est consommatrice de ressources système. En effet, lorsque l'image est exécutée sur une machine ayant un système d'exploitation donné, les bibliothèques logicielles correspondantes aux autres systèmes d'exploitation ne sont pas utilisées et consomment de la mémoire.
Il existe également une méthode de création d'une image d'une application, dite de type « langage spécifique ». Selon cette méthode, le code de l'application est compatible uniquement avec un seul système d'exploitation de la machine physique ou virtuelle et seules les bibliothèques logicielles compatibles avec ce système d'exploitation sont sélectionnées. Le code de l'application et les bibliothèques logicielles sélectionnées sont ensuite compilés ensemble pour former l'image de l'application.
L'image de l'application créée de type « langage spécifique » consomme moins de ressources système qu'une image créée de type généraliste. Cependant, la portabilité de l'image créée de type « langage spécifique » n'est pas assurée.
Il existe alors un besoin en une solution de création d'une image d'une application qui ne présente pas les inconvénients des solutions existantes.
Objet et résumé de l'invention
L'invention vise un procédé de création d'une image d'une application, cette image étant susceptible d'être utilisée pour exécuter un conteneur de cette application sur un hyperviseur. Le procédé comporte les étapes de :
— obtention d'un premier objet obtenu par compilation du code de l'application, le premier objet étant indépendant d'un système d'exploitation ;
— détermination d'un ensemble de bibliothèques logicielles requises par un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet ;
— obtention d'un deuxième objet obtenu par compilation desdites bibliothèques logicielles pour un système d'exploitation donné ; et
— assemblage du premier et du deuxième objet pour créer l'image de l'application.
Corrélativement, l'invention vise un système de création d'une image d'une application, cette image étant susceptible d'être utilisée pour exécuter un conteneur de cette application sur un hyperviseur. Ce système comporte :
— un module d'obtention d'un premier objet obtenu par compilation du code de l'application, le premier objet étant indépendant d'un système d'exploitation ;
— un module configuré pour déterminer un ensemble de bibliothèques logicielles requises par un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet ;
— un module d'obtention d'un deuxième objet obtenu par compilation desdites bibliothèques logicielles pour un système d'exploitation donné ; et
— un module d'assemblage du premier et du deuxième objet pour créer l'image de l'application.
Les caractéristiques et avantages du procédé selon l'invention présentés ci-après s'appliquent de la même façon au système selon l'invention. Le fait de compiler séparément le code de l'application des bibliothèques logicielles permet la portabilité de l'application sur divers systèmes d'exploitation, et permet de fournir l'objet de l'application, dit premier objet, sans le code source, à un tiers souhaitant construire une image compatible avec un système d'exploitation donné.
L'ensemble des bibliothèques logicielles requises par l'ensemble des appels systèmes utilisés par l'application ne comporte que les bibliothèques logicielles qui comportent les routines correspondant à ces appels.
L'invention permet d'optimiser les ressources système en comparaison avec une méthode de type généraliste, car le deuxième objet est obtenu par compilation des bibliothèques logicielles requises par l'application, et uniquement celles-ci.
Le premier objet étant indépendant d'un système d'exploitation, il est possible de le réassembler avec un autre deuxième objet pour créer une image de l'application compatible avec un autre système d'exploitation.
Le premier objet peut être dans un langage interprété tel que Java ou Python.
L'image créée peut être, par la suite, déployée dans un conteneur d'application.
Nous désignons par les bibliothèques logicielles (autrement dit les librairies) requises par l'application, les dépendances de l'application.
Nous désignons par « l'assemblage » du premier et du deuxième objet, l'édition de liens entre ces deux objets.
Au sens de l'invention, un ensemble de bibliothèques logicielles requises par l'application fait référence à toutes les bibliothèques logicielles requises par l'application.
Pareillement, nous désignons par un ensemble des appels systèmes, l'intégralité des appels systèmes utilisés par l'application.
Le premier et le deuxième objet obtenus par compilation sont des fichiers objets dans un langage cible, par exemple dans des fichiers objets conformes à un langage machine tel qu'un langage assembleur. On rappelle qu'un fichier objet est un fichier intermédiaire obtenu au cours d'un processus de compilation. Ce fichier contient des données nécessaires à l'édition de liens. Ainsi, ce fichier objet est non exécutable directement.
Dans un mode de réalisation, le premier et le deuxième objet sont binaires.
Dans un mode de réalisation, la détermination de l'ensemble des bibliothèques logicielles requises par l'application se fait à partir du premier objet compilé. Le code de l'application n'est pas divulgué pour la mise en oeuvre du procédé.
Dans un mode de réalisation, il est possible de compiler le code source puis d'effectuer l'étape de détermination de l'ensemble des bibliothèques logicielles requises par l'application à partir de l'objet compilé.
La détermination, selon l'invention, de l'ensemble des bibliothèques logicielles est une détermination automatique. Dans un mode de réalisation, le procédé selon l'invention comporte en outre une étape de calcul d'une signature du premier objet et d'une signature du deuxième objet.
L'image créée est alors caractérisée par un couple de signatures, à savoir la signature du premier objet et la signature du deuxième objet, ce qui permet de détecter une image conforme à la présente invention.
Dans un mode de réalisation, l'étape de détermination de l'ensemble des bibliothèques logicielles comporte une recherche, dans le premier objet, d'une première séquence correspondant à un appel système, l'appel système utilisé par l'application étant identifié par une deuxième séquence connexe à la première séquence.
La première séquence et la deuxième séquence connexe à la première séquence sont conformes au langage du premier objet obtenu par compilation.
Autrement dit, tous les appels système pour un système d'exploitation donnée commence par un même préfixe (première séquence au sens du brevet), la nature de l'appel système étant définie par la deuxième séquence.
Dans un mode de réalisation, la première séquence et la deuxième séquence connexe à la première séquence sont des instructions binaires conformes à une architecture externe du processeur, (ISA pour « Instruction Set Architecture »).
Dans un mode de réalisation, les appels systèmes utilisés par l'application sont de type Posix (Portable Operating System Interface, standard IEEE 1003) System Call contenus dans une liste. Dans ce mode, la deuxième séquence permet d'identifier un appel système de cette liste.
Dans un mode de réalisation particulier, un dictionnaire associe un appel système ABI (pour « Application Binary Interface ») avec des bibliothèques logicielles les implémentant. La ou les bibliothèques logicielles requises par chaque appel système sont ainsi identifiées.
Dans un mode de réalisation particulier, des dépendances d'une bibliothèque logicielle identifiée avec une ou d'autres bibliothèques logicielles sont déterminées et cette ou ces dernières sont ajoutées à une liste de l'ensemble des bibliothèques logicielles requises par l'application.
Les différents modules du système selon l'invention ne sont pas nécessairement compris dans un même dispositif.
L'invention vise également une image d'une application, cette image étant susceptible d'être utilisée pour exécuter un conteneur de cette application sur un hyperviseur. Elle comporte :
— un objet correspondant à un premier objet obtenu par compilation du code de l'application, produit lors d'un assemblage du premier objet avec un deuxième objet, des adresses mémoire d'appels système identifiés dans le premier objet étant éditées lors de l'assemblage pour pointer vers des routines correspondantes dans le deuxième objet, ledit premier objet étant indépendant d'un système d'exploitation ; et
— le deuxième objet obtenu par compilation d'un ensemble de bibliothèques logicielles requises par un ensemble des appels système utilisés par l'application pour un système d'exploitation donné. L'image de l'application conforme à l'invention peut être utilisée pour exécuter un conteneur de cette application. Le conteneur peut s'exécuter sur un hyperviseur, qui lui, s'exécute sur des ressources matérielles d'une machine physique. L'hyperviseur permet au conteneur d'application de communiquer avec les ressources matérielles de la machine physique. Une telle architecture (conteneur d'application/hyperviseur/ressources matérielles) est connue en anglais sous le nom « unikernel ».
Le procédé de l'invention permet de créer une image d'une application selon l'invention.
Dans un mode de réalisation, un conteneur d'application est exécuté à partir de l'image d'une application selon l'invention. Le conteneur est installé sur un hyperviseur.
L'invention vise également un premier programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou dans un dispositif compris dans le système selon l'invention, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé de création d'une image d'une application tel que décrit ci-dessus.
L'invention vise également un second programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou dans un dispositif compris dans le système selon l'invention, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé d'exécution d'une image selon l'invention.
Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi des supports d'information ou d'enregistrement lisibles par un ordinateur, et comportant des instructions des programmes d'ordinateur tels que mentionnés ci- dessus.
Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.
D'autre part, les supports d'information ou d'enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un des programmes est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de la méthode en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— La figure 1 est un organigramme représentant les étapes d'un procédé de création d'une image d'une application, conformément à un mode de réalisation particulier ;
— La figure 2 illustre l'architecture fonctionnelle d'un système de création d'une image selon un mode de réalisation particulier ;
— La figure 3 illustre l'architecture matérielle d'un dispositif du système de création d'une image selon un mode de réalisation particulier ;
— La figure 4 représente une image d'une application créée par le procédé proposé selon un mode de réalisation particulier ; et
— La figure 5 représente l'architecture logicielle permettant l'exécution d'une image conforme à l'invention, selon un mode de réalisation particulier.
Description détaillée
La figure 1 représente un organigramme représentant des étapes d'un procédé de création d'une image IMG d'une application, conforme à un mode de réalisation particulier.
Dans ce mode de réalisation, un code source CODE_APP de l'application a été compilé au cours d'une étape T10 qui précède la mise en oeuvre des étapes du procédé de création proposé.
Au cours d'une étape E10, un système SYS qui met en oeuvre le procédé de création d'une image obtient un premier objet 01 obtenu par compilation (T10) du code source de l'application.
Le premier objet 01 obtenu par compilation est un fichier objet dans un langage cible, par exemple un fichier objet conforme à un langage machine tel qu'un langage assembleur. On rappelle qu'un fichier objet est un fichier intermédiaire obtenu au cours d'un processus de compilation. Ce fichier contient des données nécessaires à l'édition de liens. Ainsi, ce fichier objet est non exécutable directement.
Dans un mode de réalisation particulier, le premier objet 01 est un objet binaire. Par exemple ce premier objet 01 est de type blob (Binary Large OBject). L'obtention (E10) du premier objet 01 peut consister en la réception de l'objet 01, par un moyen de communication du système ou par une lecture à partir d'un support mobile d'enregistrement sur lequel le premier objet 01 a été enregistré.
La compilation, non décrite ici, peut être effectuée par un compilateur de l'art antérieur.
Au cours d'une étape E20, le système SYS détermine l'ensemble des bibliothèques logicielles LIB requises par l'application à partir de l'ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet 01.
Dans ce mode de réalisation, le système SYS cherche dans le premier objet binaire 01 tous les différents appels systèmes utilisés pour former l'ensemble des appels systèmes. Le système SYS identifie ensuite la ou les bibliothèques logicielles requises par chaque appel système en ignorant les éventuels doublons de bibliothèques logicielles, correspondant par exemple à deux appels systèmes distincts d'une même bibliothèque, et obtient ainsi une liste de l'ensemble des bibliothèques logicielles LIB requises par l'application.
Dans un mode de réalisation particulier, la recherche des appels systèmes utilisés par l'application se base sur une recherche d'une première séquence, caractéristique d'un appel système. Une deuxième séquence connexe à la première séquence permet ensuite d'identifier l'appel système requis par l'application.
Dans un mode particulier, la première et la deuxième séquence sont des séquences binaires.
Par exemple, la première séquence binaire est caractéristique d'un appel système. Plus particulièrement, un appel système spécifique de type Posix comporte deux parties : une première partie identique pour tous les appels système, et une deuxième partie qui caractérise cet appel système spécifique. La première partie identique est la première séquence binaire recherchée, alors que la deuxième partie représente la deuxième séquence connexe à la première séquence. Les deuxièmes parties sont par exemple contenues ou référencées dans une liste, permettant ainsi d'identifier un appel système à partir de cette liste.
Dans un mode de réalisation particulier, un dictionnaire associe un appel système ABI (pour « Application Binary Interface ») avec des bibliothèques logicielles les implémentant. Le système SYS identifie ainsi la ou les bibliothèques logicielles requises par chaque appel système.
Dans un mode de réalisation particulier, des dépendances d'une bibliothèque logicielle identifiée avec une ou d'autres bibliothèques logicielles sont déterminées et cette ou ces dernières sont ajoutées à la liste des bibliothèques logicielles requises par l'application.
Au cours d'une étape E30, le système SYS obtient un deuxième objet 02 généré par compilation de l'ensemble des bibliothèques logicielles LIB déterminé à l'étape E20 pour un système d'exploitation donné. Ce deuxième objet 02 est ainsi personnalisé pour ce système d'exploitation. Ce deuxième objet 02 est également un fichier objet. L'ensemble des bibliothèques logicielles LIB peut être compilé par le système SYS au cours de l'étape E30 elle-même, le résultat de la compilation est le deuxième objet 02.
Dans un mode de réalisation particulier, le deuxième objet 02 est un objet binaire. Par exemple ce deuxième objet 02 est de type blob.
Dans un mode de réalisation particulier, une signature SIG1, SIG2 est calculée pour chacun des objets 01 et 02 au cours d'une étape E40.
On entend par signature une empreinte calculée sur tout ou partie d'un objet O et caractérisant ce dernier.
La signature SIG1 est calculée sur une partie de l'objet 01 qui n'est pas modifiée lors de l'étape d'assemblage E50, décrite ultérieurement.
Dans un mode de réalisation particulier, la signature de l'objet 01 correspond à la liste de l'ensemble des appels systèmes identifiés dans cet objet 01.
Dans un mode de réalisation particulier, la signature de l'objet 02 correspond à la liste des appels systèmes qu'il implémente, ainsi que le système d'exploitation dont le support est visé.
Contrairement à une image créée par un procédé de l'état de l'art où le code et les bibliothèques logicielles sont compilés ensemble, l'image créée selon le procédé de création proposé est caractérisée par un couple des deux signatures (SIG1, SIG2) correspondant aux signatures des deux objets 01 et 02.
Au cours d'une étape E50, le premier objet 01 et le deuxième objet 02 sont assemblés (« link » en anglais) pour créer l'image IMG de l'application. Dans cette étape E50, les adresses mémoire des appels système identifiés dans le premier objet 01 sont éditées pour pointer vers les routines correspondantes dans le deuxième objet 02. Ainsi, cette édition produit un objet O'I correspondant au premier objet 01.
L'image créée IMG peut être exécutée, au cours d'une étape qui fait suite au procédé de création, pour obtenir un conteneur de l'application. L'application peut ainsi être exécutée sur une machine physique ou virtuelle compatible avec le système d'exploitation donné utilisé pour obtenir le deuxième objet 02.
Plusieurs instances de l'image IMG peuvent être générées pour exécuter l'application sur différentes machines physiques ou virtuelles compatibles avec le système d'exploitation donné utilisé pour obtenir le deuxième objet 02.
Dans un autre mode de réalisation, le procédé de création ne dispose en entrée que du code source CODE_APP. Le système SYS compile le code source CODE_APP au cours de l'étape E10, le résultat de la compilation représentant le premier objet 01.
Dans un autre mode de réalisation, l'étape E30 de génération du deuxième objet 02 par compilation des bibliothèques logicielles LIB est effectuée par un dispositif ne faisant pas partie du système SYS. Le système SYS reçoit, au cours de l'étape E30, le deuxième objet 02.
Ce procédé de création d'une image trouve une application avantageuse dans le cadre de la construction d'images système de type « unikernel », dans lequel un exécutable d'une application comprend l'ensemble des routines du système d'exploitation suffisantes pour son exécution dans un environnement de virtualisation système. Grâce au procédé de création proposé, l'exécutable de l'application comprend uniquement les routines du système d'exploitation strictement nécessaires pour son exécution.
La figure 2 représente l'architecture fonctionnelle d'un système SYS de création d'une image IMG d'une application, conformément à un mode de réalisation de l'invention.
Le système SYS comporte :
— un module MOD_01 d'obtention d'un premier objet 01 obtenu par compilation (E10, T10) du code CODE_APP de l'application ;
— un module MODJ.IB configuré pour déterminer un ensemble de bibliothèques logicielles LIB requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet 01;
— un module M0D_02 d'obtention d'un deuxième objet 02 obtenu par compilation (E30) desdites bibliothèques logicielles LIB, pour un système d'exploitation donné; et
— un module MODJ.INK d'assemblage des objets 01 et 02 pour créer l'image IMG de l'application.
Dans un mode de réalisation, le premier objet 01 et/ou le deuxième objet 02 sont des fichiers objets.
Le module M0D_01 d'obtention d'un premier objet 01 peut recevoir en entrée le premier objet 01 ou le code CODE_APP de l'application.
Le module M0D_01 fournit en sortie le premier objet 01.
Le module MOD_LIB reçoit en entrée le premier objet 01.
Le module MOD_LIB génère en sortie l'ensemble des bibliothèques logicielles LIB requises par l'application, comme décrit précédemment.
Le module M0D_02 d'obtention d'un deuxième objet 02 reçoit en entrée l'ensemble LIB des bibliothèques logicielles requises par l'application, pour un système d'exploitation donné, et fournit en sortie le deuxième objet 02.
Le module MOD_LINK d'assemblage des objets 01 et 02 requiert en entrées le premier objet 01 et le deuxième objet 02. En sortie, il fournit l'image IMG de l'application par édition de liens, comme décrit précédemment.
Les modules M0D_01, M0D_02, MOD_LIB et MODJ.INK peuvent être mis en oeuvre par différents dispositifs du système SYS.
Dans le mode de réalisation décrit ici, chaque dispositif du système SYS conforme à l'invention a l'architecture d'un ordinateur, telle qu'illustrée à la figure 3. Elle comprend notamment un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici.
La mémoire morte 9 d'un dispositif compris dans le système SYS de création d'une image selon l'invention constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur Prog conforme à l'invention.
La mémoire 10 d'un dispositif compris dans le système SYS permet d'enregistrer des variables utilisées pour l'exécution des étapes de l'invention, telles que le code CODE_APP de l'application, une liste des appels systèmes utilisés par l'application, une liste des appels systèmes de type Posix System Call, un résultat temporaire ou définitif de recherche d'appels systèmes, etc.
Le programme d'ordinateur Prog définit des modules fonctionnels et logiciels ici, configurés pour permettre à un système SYS de créer une image IMG d'une application. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 d'un dispositif du système SYS cités précédemment.
La figure 4 représente une image IMG d'une application, l'image IMG étant obtenue par exécution du procédé de création proposé.
L'image IMG est un programme exécutable par une machine physique ou virtuelle.
L'image IMG comporte :
— un objet O'I correspondant au premier objet 01 obtenu par compilation (E10, T10) du code source CODE_APP de l'application, produit lors de l'assemblage avec un deuxième objet 02 ; et
— le deuxième objet 02 obtenu par compilation (E30) d'un ensemble de bibliothèques logicielles LIB requises par l'application.
L'image IMG conforme à l'invention est caractérisée par un couple de signatures SIG1 et SIG2 correspondant aux signatures du premier objet 01 et du deuxième objet 02.
La figure 5 illustre l'architecture logicielle permettant l'exécution d'une image IMG conforme à l'invention, selon un mode de réalisation de l'invention.
Dans ce mode de réalisation, pour exécuter l'application sur une machine physique ORD, un conteneur d'application C_APP est exécuté à partir de l'image IMG de l'application, et installé sur un hyperviseur HYP de la machine ORD. L'hyperviseur HYP est mis en oeuvre au-dessus de l'infrastructure matérielle PHY de la machine ORD.
Dans un mode de réalisation particulier, l'image IMG est une image de type « unikernel » et le conteneur d'application C_APP est une machine virtuelle s'exécutant sur l'infrastructure matérielle PHY de la machine ORD.
La machine physique ORD a l'architecture d'un ordinateur, similaire à l'architecture présentée à la figure 3. Cette architecture logicielle peut par exemple être utilisée dans un réseau de communication mobile de 5eme génération (5G) dans lequel des fonctions réseaux virtualisées sont mises en oeuvre, pour assurer à la fois la performance et la portabilité de la fonction réseau virtualisée.
L'invention vise aussi un programme d'ordinateur Proglmg qui définit des modules fonctionnels et logiciels ici, configurés pour permettre à une machine physique ORD d'exécuter une image IMG conforme à l'invention. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 de la machine ORD : un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11.
La mémoire morte 9 de la machine ORD constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 de la machine ORD et sur lequel est enregistré ici un programme d'ordinateur Proglmg conforme à l'invention, permettant l'exécution de l'image IMG présentée à la figure 4.
La mémoire 10 de la machine ORD permet d'enregistrer des variables utilisées pour l'exécution des étapes d'exécution de l'image IMG conforme à l'invention.

Claims

REVENDICATIONS
1. Procédé de création d'une image d'une application, ladite image étant susceptible d'être utilisée pour exécuter un conteneur de la dite application sur un hyperviseur, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes :
— obtention (E10) d'un premier objet (01) obtenu par compilation (E10, T10) du code (CODE_APP) de l'application, ledit premier objet étant indépendant d'un système d'exploitation ;
— détermination (E20) d'un ensemble de bibliothèques logicielles (LIB) requises par un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet (01) ;
— obtention (E30) d'un deuxième objet (02) obtenu par compilation (E30) desdites bibliothèques logicielles (LIB) pour un système d'exploitation donné ; et
— assemblage (E50) desdits objets pour créer ladite image (IMG) de l'application.
2. Procédé selon la revendication 1 comportant en outre une étape (E40) de calcul de signatures (SIG1, SIG2) de chacun desdits objets (01, 02).
3. Procédé selon la revendication 1 ou 2, dans lequel l'étape (E20) de détermination d'un ensemble de bibliothèques logicielles comporte une recherche, dans ledit premier objet (01), d'une première séquence correspondant à un appel système, une deuxième séquence connexe à la première séquence permettant d'identifier l'appel système utilisé par l'application, lesdites première et deuxième séquences étant conformes au langage dudit premier objet (01).
4. Programme d'ordinateur (Prog) comportant des instructions pour la création d'une image d'une application selon une des revendications 1 à 3, lorsque ledit programme est exécuté par un ordinateur.
5. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (Prog) comprenant des instructions pour l'exécution des étapes d'un procédé de création d'une image d'une application selon une des revendications 1 à 3.
6. Système (SYS) de création d'une image d'une application, ladite image étant susceptible d'être utilisée pour exécuter un conteneur de la dite application sur un hyperviseur, ledit système étant caractérisé en ce qu'il comporte:
— un module (M0D_01) d'obtention d'un premier objet (01) obtenu par compilation (E10, T10) du code (CODE_APP) de l'application, ledit premier objet étant indépendant d'un système d'exploitation ; — un module (MODJ.IB) configuré pour déterminer un ensemble de bibliothèques logicielles (LIB) requises par un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet (01) ;
— un module (MOD_02) d'obtention d'un deuxième objet (02) obtenu par compilation (E30) desdites bibliothèques logicielles pour un système d'exploitation donné ; et
— un module (MOD_LINK) d'assemblage desdits objets (01, 02) pour créer ladite image (IMG) de l'application.
7. Image (IMG) d'une application, ladite image étant susceptible d'être utilisée pour exécuter un conteneur de la dite application sur un hyperviseur, ladite image étant caractérisée en ce qu'elle comporte:
— un objet (O'I) correspondant à un premier objet (01) obtenu par compilation (E10, T10) du code de l'application, produit lors d'un assemblage dudit premier objet (01) avec un deuxième objet (02), des adresses mémoire d'appels système identifiés dans ledit premier objet (01) étant éditées lors dudit assemblage pour pointer vers des routines correspondantes dans ledit deuxième objet (02), ledit premier objet étant indépendant d'un système d'exploitation ; et
— ledit deuxième objet (02) obtenu par compilation (E30) d'un ensemble de bibliothèques logicielles, requises par un ensemble des appels systèmes utilisés par l'application, pour un système d'exploitation donné.
8. Procédé d'installation, sur un hyperviseur, d'un conteneur d'application (C_APP) exécuté à partir d'une image (IMG) d'une application selon la revendication 7.
9. Programme d'ordinateur (Proglmg) comportant des instructions pour l'exécution d'une image (IMG) selon la revendication 7, lorsque ledit programme est exécuté par un ordinateur.
10. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (Proglmg) comprenant des instructions pour l'exécution d'une image (IMG) selon la revendication 7.
PCT/FR2019/050632 2018-03-20 2019-03-20 Procédé et système pour créer une image d'une application WO2019180376A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1852362 2018-03-20
FR1852362A FR3079328B1 (fr) 2018-03-20 2018-03-20 Procede et systeme pour creer une image d'une application

Publications (1)

Publication Number Publication Date
WO2019180376A1 true WO2019180376A1 (fr) 2019-09-26

Family

ID=62816703

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/050632 WO2019180376A1 (fr) 2018-03-20 2019-03-20 Procédé et système pour créer une image d'une application

Country Status (2)

Country Link
FR (1) FR3079328B1 (fr)
WO (1) WO2019180376A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115167874B (zh) * 2022-08-19 2023-04-14 禾多科技（北京）有限公司 自动驾驶软件镜像部署方法、装置、电子设备和可读介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170139694A1 (en) * 2015-11-16 2017-05-18 Qualcomm Innovation Center, Inc. System and method for link time optimization
US20170364377A1 (en) * 2016-06-15 2017-12-21 International Business Machines Corporation Specialized micro-hypervisors for unikernels

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170139694A1 (en) * 2015-11-16 2017-05-18 Qualcomm Innovation Center, Inc. System and method for link time optimization
US20170364377A1 (en) * 2016-06-15 2017-12-21 International Business Machines Corporation Specialized micro-hypervisors for unikernels

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BJORN DE SUTTER ET AL: "Link-time binary rewriting techniques for program compaction", ACM TRANSACTIONS ON PROGRAMMING LANGUAGE AND SYSTEMS, ACM, NEW YORK, NY, vol. 27, no. 5, 1 September 2005 (2005-09-01), pages 882 - 945, XP058144900, ISSN: 0164-0925, DOI: 10.1145/1086642.1086645 *
CHRISTIAN COLLBERG ET AL: "Slinky: Static Linking Reloaded", USENIX,, 14 March 2005 (2005-03-14), pages 1 - 14, XP061012917 *

Also Published As

Publication number Publication date
FR3079328B1 (fr) 2022-01-21
FR3079328A1 (fr) 2019-09-27

Similar Documents

Publication Publication Date Title
JP6963671B2 (ja) アプリケーションのパターンおよびリスク評価に基づくコンプライアンスを認識するランタイム生成
EP2649522B1 (fr) Methode de mise a disposition d'une application en tant que librairie dans une machine virtuelle
FR2904709A1 (fr) Dispositif et procedes de mise a jour de micrologiciel
EP2649523B1 (fr) Méthode de compilation d'un code intermédiaire d'une application
US10416973B2 (en) Analysis of source code for deployment
US8806475B2 (en) Techniques for conditional deployment of application artifacts
US10671384B1 (en) Proactive seeding of build Artifacts
WO2012000949A1 (fr) Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant
US9594559B2 (en) Binary file for computer program having multiple executable code variants for a function that are executable on a same processor architecture
WO2015121418A2 (fr) Procédé de déploiement d'un ensemble d'application(s) logicielle(s)
WO2019180376A1 (fr) Procédé et système pour créer une image d'une application
WO2021130420A1 (fr) Procédé et dispositif mettant en œuvre ce procédé pour générer et installer un code exécutable dans la mémoire d'un noyau d'une machine virtuelle depuis un hyperviseur
CN116069366A (zh) 客户端应用程序更新方法及装置、存储介质及电子设备
EP2674860A1 (fr) Procédé de traitement de données par un module de navigation
WO2006048378A1 (fr) Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif
FR2906382A1 (fr) Procedes et dispositifs pour optimiser le traitement xml
EP4018313B1 (fr) Récuperateur de données dans un dispositif électronique
CN117111904B (zh) 用于将Web应用自动转换成无服务器函数的方法和系统
FR3029657A1 (fr) Procede de fourniture d'un service informatique et systeme informatique pour la mise en œuvre du procede.
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
EP4123492A1 (fr) Mise en partage d'une fonction d'une application définie en langage orienté objet
CN115686545A (zh) 应用程序迁移方法和装置、电子设备和可读存储介质
CN117111904A (zh) 用于将Web应用自动转换成无服务器函数的方法和系统
EP2056196A1 (fr) Procédé de réalisation et de traitement d'appel de procédure, système et produit programme d'ordinateur correspondant
FR3108747A1 (fr) Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19716468

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19716468

Country of ref document: EP

Kind code of ref document: A1