CN112860316B - Kernel and BSP transplanting method of openEular open source system - Google Patents
Kernel and BSP transplanting method of openEular open source system Download PDFInfo
- Publication number
- CN112860316B CN112860316B CN202110178098.XA CN202110178098A CN112860316B CN 112860316 B CN112860316 B CN 112860316B CN 202110178098 A CN202110178098 A CN 202110178098A CN 112860316 B CN112860316 B CN 112860316B
- Authority
- CN
- China
- Prior art keywords
- openeular
- open source
- function
- patch1
- patch2
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000012545 processing Methods 0.000 claims abstract description 7
- 230000008569 process Effects 0.000 claims description 30
- 239000008186 active pharmaceutical agent Substances 0.000 claims description 25
- 238000013508 migration Methods 0.000 claims description 7
- 230000005012 migration Effects 0.000 claims description 7
- 238000013509 system migration Methods 0.000 claims description 7
- 230000002093 peripheral effect Effects 0.000 claims description 4
- 230000001419 dependent effect Effects 0.000 claims description 3
- 230000000694 effects Effects 0.000 claims description 3
- 230000007246 mechanism Effects 0.000 claims description 3
- 238000013515 script Methods 0.000 claims description 3
- 230000008859 change Effects 0.000 claims description 2
- 230000014509 gene expression Effects 0.000 claims description 2
- 238000012546 transfer Methods 0.000 claims description 2
- 238000011161 development Methods 0.000 abstract description 18
- 230000001737 promoting effect Effects 0.000 abstract description 2
- 238000004458 analytical method Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000007774 longterm Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a kernel of an openEular open source system and a BSP transplanting method, comprising the following steps: acquiring a related patch1 set from sdk corresponding to the chip, wherein the patch1 set comprises all program source code series patches supporting functions of each module of the chip; analyzing the patch1 set, removing partial codes which are merged into the openEular open source system, and generating a patch2 set; combining each patch in the patch2 set by adopting a git tool; and merging the processing result into an openEular open source system, and compiling and debugging the system on the basis. According to the invention, sdk of different chip manufacturers can be transplanted to the openEuler operating system, the probability of errors can be reduced to the greatest extent, and the development threshold of a user is reduced, so that a developer can quickly enter into work, the overall development efficiency is improved, and technical power is provided for promoting the wide application of the domestic operating system openEuler.
Description
Technical Field
The invention relates to the technical field of transplanting of openEuler operating systems, in particular to a kernel of an openEuler open source system and a BSP transplanting method.
Background
The mainstream Linux operation systems such as ubuntu, redhat, centos or fedora in the world all last for decades, and due to the open source characteristic, a perfect ecological environment is formed, and the Linux operation systems are widely and intensively supported by a plurality of chip manufacturers, so that the Linux operation systems are widely and deeply applied in the embedded field. openeuler is an excellent domestic open source operating system, and is initiated by China, but the popularity is being improved due to the fact that the start is late, and the openeuler is not supported by the bottom layer of broad chip manufacturers at present. Various chip drivers from cpu, mcu to network, storage, clock, etc. are not applied in openeuler home-made systems by many chip manufacturers. Without the support of the bottom layer, the development of the upper layer application is also affected, and new functions and the like are not developed.
Disclosure of Invention
The invention aims to provide a kernel of an openEuler open source system and a BSP transplanting method, which can transplant sdk of different chip manufacturers to an openEuler operating system, reduce the probability of errors to the greatest extent, and reduce the development threshold of a user, so that a developer can quickly enter into work, improve the overall development efficiency, and provide technical power for promoting the wide application of the domestic operating system openEuler.
In order to achieve the above purpose, the present invention adopts the following technical scheme:
a kernel of an openEular open source system and a BSP transplanting method are provided, wherein the transplanting method comprises the following steps:
s1, acquiring a related patch1 set from sdk corresponding to a chip, wherein the patch1 set comprises all program source code series patches supporting functions of each module of the chip;
s2, analyzing the patch1 set, removing partial codes which are merged into the openEular open source system, and generating a patch2 set;
s3, merging each patch in the patch2 set by adopting a git tool;
s4, merging the processing result in the step S3 into an openEular open source system, and compiling and debugging the system on the basis.
Further, in step S2, the process of rejecting the partial code that has been merged into the openEular open source system to generate the patch2 set includes the following steps:
s21, extracting a subject character string in each comment in the patch1 set, generating a certain amount of search bases, defining the ith search base as title (i), wherein i=1, 2, …, n and n are the total number of the search bases extracted from the patch1 set;
s22, sequentially selecting each retrieval basis, carrying out retrieval query comparison in a target system, namely an openEular open source system, and deleting a patch corresponding to the retrieval basis from a patch1 set if the same retrieval basis exists in the target system;
s23, integrating the rest patch sets to generate a patch2 set as a code resource for the subsequent system migration.
Further, in step S22, each search criterion is selected in turn, search query comparison is performed in the target system, that is, the openEular open source system, and if the target system has the same search criterion, deleting the patch corresponding to the search criterion from the patch1 set means that:
and comparing logs summarized by the openEular open source system one by adopting an automatic script, and deleting a patch corresponding to the subject character string from the patch1 set if the subject character string of the same comment as the extracted subject character string exists.
Further, in step S3, the process of merging each patch in the set of patches 2 by using the git tool includes the following steps:
s31, in the execution process, judging whether a conflict exists in real time, if so, turning to a step S32, otherwise, executing a merging flow until merging is completed, and ending the flow;
s32, judging the conflict type of the current conflict, if the conflict type is context conflict, turning to step S33, and if the conflict type is code semantic conflict, turning to step S34;
s33, forcedly combining, continuing to execute the combining process until the combining is completed, and ending the process;
s34, judging the code semantic conflict type:
if the conflict type is a compatibility problem caused by inconsistent kernel version systems of the API interface, comparing according to specific API interface parameters; if the API interface is unique or a small amount of API interfaces are called by other modules, revising the API of the target system according to the change in the current patch2 set;
if the conflict type is the problem caused by that a large number of modified APIs are called by other various modules in the target system, modifying the APIs in the patch2 set, reserving interfaces in the target system, and revising and changing the transfer parameters of the APIs in the patch2 and the implementation inside the function body; the revision process includes: digesting the function semantic understanding function in the target system, and modifying the parameters and the function internal logic in the patch2 under the condition that the function parameters and the functions in the target system are unchanged, so as to ensure that the function forms of the two functions are different but the function forms are consistent;
if the conflict type is that the problem of the internal implementation of the function is changed, modifying the function content in the patch2 under the condition of not changing the purpose and the execution flow of the function;
if the conflict type is other, the semantics and the implementation content of the function are followed, the context adjustment is carried out on the function under the condition of not changing a kernel mechanism and a driving implementation mode, and the revision principles of the function with the same function but different form expressions are satisfied by deleting and adding partial codes;
after the conflict is eliminated, the merging process is continued until the merging is completed, and the process is ended.
Further, in step S4, the compiling process for the system includes the following steps:
and verifying the effect and the integrity of system migration, and if undefined variables are introduced, searching and introducing the dependent patch of the variables until the compiling is completely passed.
Further, in step S4, the process of debugging the system includes the following steps:
checking and verifying various peripheral functions and device performances of the chip, and if a functional problem occurs, searching relevant functional patch again from sdk to compensate the existing functional problem.
Compared with the prior art, the technical scheme of the invention has the remarkable beneficial effects that:
(1) Under sdk development mode resources provided when a plurality of chip manufacturers popularize and apply the chips, the patch code revision and upgrading method in kernel development is utilized, and the patch code revision and upgrading method is quickly introduced into an openeuler system after programming processing, analysis and deleting of the patch, so that the openeuler system can quickly realize support for the chip manufacturers, and the transplanting process is quick and efficient.
(2) At present, the mode of sdk is used by all manufacturers to be popularized, and the mode is transplanted to a domestic operating system on the basis of sdk, so that the method has wide use value; the open source is widely applied.
(3) Time and cost are effectively saved.
It should be understood that all combinations of the foregoing concepts, as well as additional concepts described in more detail below, may be considered a part of the inventive subject matter of the present disclosure as long as such concepts are not mutually inconsistent. In addition, all combinations of claimed subject matter are considered part of the disclosed inventive subject matter.
The foregoing and other aspects, embodiments, and features of the present teachings will be more fully understood from the following description, taken together with the accompanying drawings. Other additional aspects of the invention, such as features and/or advantages of the exemplary embodiments, will be apparent from the description which follows, or may be learned by practice of the embodiments according to the teachings of the invention.
Drawings
The drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures may be represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. Embodiments of various aspects of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:
FIG. 1 is a flow chart of a kernel and BSP migration method of the openEular open source system of the present invention.
Fig. 2 is a schematic diagram of an SDK analysis process.
Fig. 3 is a schematic diagram of the system migration principle.
FIG. 4 is a schematic diagram of the process analysis of the patch1 set.
FIG. 5 is a schematic diagram of an example of a patch1 set processing analysis.
Fig. 6 is a flow chart of conflict API resolution.
Detailed Description
For a better understanding of the technical content of the present invention, specific examples are set forth below, along with the accompanying drawings.
First, some terms in the present invention will be explained:
(1) Patch refers to a Patch, meaning a file Patch or the like, and is also one type of computer command program.
Modifications are often required in the code development process on the basis of source codes, and the code is generally submitted in the form of a patch when being merged, so that the generation of the patch and the application of the patch need to be understood. The so-called patch is in fact a file comparison, and the use of diff commands (ref 2) on Linux gives a patch.
diff-uprN test1/test2/>test.patch
The command compares code differences under test1 and test2 paths, and if some content does not need to be compared, then-include-from=xx is used after diff command, and in xx it is indicated which information does not need to be compared, such as git information.
(2)SDK(Software Development Kit)
When the chip manufacturer issues the chip product, the chip manufacturer distributes own sdk (Software Development Kit) software development kit. Typically, a collection of development tools are created by some software engineers for a particular software package, software framework, hardware platform, operating system, etc. when the application software is built. Popular: refers to a toolkit provided by a third party service provider that implements a function of a software product. Appearance form: generally in the form of collections kpi and documents, examples, tools.
(3) git (distributed version control system)
GitIs an open-source distributed version control system and can effectively and rapidly process project version management from small to very large.
Git is version control software of an open source developed by Linus Torvalds to help manage Linux kernel development.
Torvalds began to develop Git as a transitional solution to replace BitKeeper.
Referring to fig. 1, the present invention refers to a kernel of an openEular open source system and a BSP migration method, where the migration method includes the following steps:
s1, acquiring a related patch1 set from sdk corresponding to the chip, wherein the patch1 set comprises all program source code series patches supporting functions of each module of the chip.
S2, analyzing the patch1 set, removing partial codes which are merged into the openEular open source system, and generating a patch2 set.
S3, merging each patch in the patch2 set by adopting a git tool.
S4, merging the processing result in the step S3 into an openEular open source system, and compiling and debugging the system on the basis.
According to the invention, under sdk development mode resources provided when a plurality of chip manufacturers popularize and apply the chips, the patch code revision and upgrading method in kernel development is utilized, and after the patch is subjected to programming processing, analysis and deletion, the patch code revision and upgrading method is quickly introduced into an openeuler system, so that the openeuler system can quickly realize the support of the chip manufacturers.
The method for adding the chip related driving codes by most merchants adopts a code management tool git special for an open source community, and then revises and adds each functional module in a patch mode to realize the support, update, fix bug and the like of the functional module of the chip.
Thus, the code of sdk chip manufacturer is obtained, and the source code of the transplanted code can be obtained completely by using the tool.
In the system, a chip manufacturer sdk is an important code resource which is referred by me, first, we need to know the development flow of manufacturer sdk, the development flow of general manufacturer sdk will select a long-term support development of a version of kernel, and then perform continuous development on this basis, for example, the long-term support version of kernel version5.4 LTS, where the development mode is that a part of codes are relevant driving codes of the chip, chip series 1, chip series 2, a certain device driver 1, and a certain device driver 2, where the chip series can be from rk1860 to the latest rk3399 chip series, and peripheral modules are chips integrated in cpu or on a certain device board from cpu, USB HOST, EMMC, PCIE, UART, I2C, SPI, ETHERNET, GPU, GPIO, and the like.
With reference to fig. 2, to obtain the chip direct correlation code, we use to remove the kernel base version and post-added tagxx. Xx, leaving manufacturer development and merge branches, and the specific operation method can further have a git management tool to process: git commit.
The series of patches is an important code component for the manufacturer sdk to directly support the chip series. We call the patch1 set.
In order to quickly transplant, the SDK of a chip manufacturer is an important code resource which is referred by us, the related patch1 set is obtained in SDK, the patch1 set is a series of patches supporting the functions of each module of the chip, and the patch1 set is processed and screened and then is combined into an object system openEluer, and then compiling and debugging are carried out on the basis. And debugging part of the functional problems one by one. The specific process is shown in fig. 3.
In sdk, a set of related patch1 is obtained, where the set of patch1 is a program source code series patch supporting the functions of each module of the chip, and the purpose of the set of patches is to incorporate the series of patches into the target system, i.e. the openeluer kernel herein. Prior to merging, we analyze the patch1 set because if the code has been merged into the openeluer open source system, if any, stripping is to be done from the target system. The stripping method is to compare logs summarized by the openeluer system one by taking the subjects of the patch as important retrieval basis according to the characteristics of the patch, if the same subjects of the comment exist, the log is deleted from the patch1 set, and the method can be realized by adopting automation of scripts, and an automation template is shown in figure 5.
Referring to FIG. 4, the specific patch1 set sort analysis process includes the following steps:
1) The subject character string in each comment in the patch1 is extracted and used as an important retrieval basis, and the basis is defined as title.
2) And (3) searching and inquiring the target system, namely the OpenEluer, to compare, and deleting the patch corresponding to the title in the patch1 if the title exists in the target system.
3) The reserved patch set becomes a patch2 set, and the patch set is an important code resource for the subsequent system migration.
Through the git tool, each patch in the set of patches 2 can be merged, and the merging and pooling can take the following common cases:
1) Successful merging without any conflicts and problems.
2) Only context conflicts can be forced to merge by manual methods. The treatment method comprises the following steps:
git am xxxx.patch
git apply--reject xxxx.patch
edit edit edit……
git add xx.c
git am–resolve。
3) Content conflict of code semantics as shown in fig. 6:
(a) The compatibility problem caused by inconsistent kernel version systems of the API interfaces can be compared according to specific API interface parameters. If the API interface is unique or a small amount of the API interface is called by other modules, the API in the target system can be revised by the API of the original system according to the consistency of the current patch2 set.
(b) If a large number of modified APIs in the target system are called by other various modules, the APIs in the patch2 set are modified, and the changes of the function parameters and the changes inside the function body are compared and researched.
(c) The problem of realizing the inside of the function is changed, the method for realizing the function needs to be deeply understood, and the content of the function in the patch2 is modified under the condition that the intention and the execution flow of the function are not changed in the continuous conflict.
4) In other cases, the semantics of the function itself and the implementation content are followed, and revisions are made without changing the kernel mechanism and driving the implementation mode.
After the completion of the latch 2 merge, further compilation and debugging of the system is required.
The compiling problem is that the effect and the integrity of the first step verification system migration are possibly caused by introducing certain variables, which are undefined and need to be searched together by the dependent patch of the variables. The compiling is completely passed. Patch2 through sdk _Patch in FIG. 3 are both this flow.
The debugging problem is to pay attention to checking and verifying the performances of various peripheral function equipment of the chip, and in the process, the related function patch is searched again from sdk to make up for the actual problem of the function in the process. See FIGS. 3, patch2 through sdk _patch.
Aspects of the invention are described in this disclosure with reference to the drawings, in which are shown a number of illustrative embodiments. The embodiments of the present disclosure need not be defined to include all aspects of the present invention. It should be understood that the various concepts and embodiments described above, as well as those described in more detail below, may be implemented in any of a number of ways, as the disclosed concepts and embodiments are not limited to any implementation. Additionally, some aspects of the disclosure may be used alone or in any suitable combination with other aspects of the disclosure.
While the invention has been described with reference to preferred embodiments, it is not intended to be limiting. Those skilled in the art will appreciate that various modifications and adaptations can be made without departing from the spirit and scope of the present invention. Accordingly, the scope of the invention is defined by the appended claims.
Claims (5)
1. The kernel of the openEular open source system and the BSP transplanting method are characterized in that the transplanting method comprises the following steps:
s1, acquiring a related patch1 set from sdk corresponding to a chip, wherein the patch1 set comprises all program source code series patches supporting functions of each module of the chip;
s2, analyzing the patch1 set, removing partial codes which are merged into the openEular open source system, and generating a patch2 set;
s3, merging each patch in the patch2 set by adopting a git tool;
s4, merging the processing result in the step S3 into an openEular open source system, and compiling and debugging the system on the basis;
in step S3, the process of merging each patch in the set of patches 2 by using the git tool includes the following steps:
s31, in the execution process, judging whether a conflict exists in real time, if so, turning to a step S32, otherwise, executing a merging flow until merging is completed, and ending the flow;
s32, judging the conflict type of the current conflict, if the conflict type is context conflict, turning to step S33, and if the conflict type is code semantic conflict, turning to step S34;
s33, forcedly combining, continuing to execute the combining process until the combining is completed, and ending the process;
s34, judging the code semantic conflict type:
if the conflict type is a compatibility problem caused by inconsistent kernel version systems of the API interface, comparing according to specific API interface parameters; if the API interface is unique or a small amount of API interfaces are called by other modules, revising the API of the target system according to the change in the current patch2 set;
if the conflict type is the problem caused by that a large number of modified APIs are called by other various modules in the target system, modifying the APIs in the patch2 set, reserving interfaces in the target system, and revising and changing the transfer parameters of the APIs in the patch2 and the implementation inside the function body; the revision process includes: digesting the function semantic understanding function in the target system, and modifying the parameters and the function internal logic in the patch2 under the condition that the function parameters and the functions in the target system are unchanged, so as to ensure that the function forms of the two functions are different but the function forms are consistent;
if the conflict type is that the problem of the internal implementation of the function is changed, modifying the function content in the patch2 under the condition of not changing the purpose and the execution flow of the function;
if the conflict type is other, the semantics and the implementation content of the function are followed, the context adjustment is carried out on the function under the condition of not changing a kernel mechanism and a driving implementation mode, and the revision principles of the function with the same function but different form expressions are satisfied by deleting and adding partial codes;
after the conflict is eliminated, the merging process is continued until the merging is completed, and the process is ended.
2. The kernel and BSP migration method of the openEular open source system according to claim 1, wherein in step S2, the process of rejecting the partial code already incorporated in the openEular open source system to generate the patch2 set includes the following steps:
s21, extracting a subject character string in each comment in the patch1 set, generating a certain amount of search bases, defining the ith search base as title (i), wherein i=1, 2, …, n and n are the total number of the search bases extracted from the patch1 set;
s22, sequentially selecting each retrieval basis, carrying out retrieval query comparison in a target system, namely an openEular open source system, and deleting a patch corresponding to the retrieval basis from a patch1 set if the same retrieval basis exists in the target system;
s23, integrating the rest patch sets to generate a patch2 set as a code resource for the subsequent system migration.
3. The kernel and BSP migration method of openEular open source system according to claim 2, wherein in step S22, each search criterion is selected in turn, search query comparison is performed in the target system, i.e. the openEular open source system, and if the same search criterion exists in the target system, deleting the corresponding patch from the patch1 set means that:
and comparing logs summarized by the openEular open source system one by adopting an automatic script, and deleting a patch corresponding to the subject character string from the patch1 set if the subject character string of the same comment as the extracted subject character string exists.
4. The kernel and BSP migration method of openEular open source system according to claim 1, wherein in step S4, the compiling process of the system comprises the following steps:
and verifying the effect and the integrity of system migration, and if undefined variables are introduced, searching and introducing the dependent patch of the variables until the compiling is completely passed.
5. The kernel and BSP migration method of openEular open source system according to claim 1, wherein in step S4, the process of debugging the system comprises the following steps:
checking and verifying various peripheral functions and device performances of the chip, and if a functional problem occurs, searching relevant functional patch again from sdk to compensate the existing functional problem.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110178098.XA CN112860316B (en) | 2021-02-08 | 2021-02-08 | Kernel and BSP transplanting method of openEular open source system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110178098.XA CN112860316B (en) | 2021-02-08 | 2021-02-08 | Kernel and BSP transplanting method of openEular open source system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112860316A CN112860316A (en) | 2021-05-28 |
| CN112860316B true CN112860316B (en) | 2024-03-08 |
Family
ID=75989424
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110178098.XA Active CN112860316B (en) | 2021-02-08 | 2021-02-08 | Kernel and BSP transplanting method of openEular open source system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112860316B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113535230B (en) * | 2021-06-07 | 2022-09-23 | 上海古鳌电子科技股份有限公司 | Method and system for dynamically adapting engineering source code to different hardware resources |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103608778A (en) * | 2011-05-13 | 2014-02-26 | 安蒂克斯实验室有限公司 | Method of distributing multi-user software application |
| CN107992291A (en) * | 2017-11-16 | 2018-05-04 | 上海南潮信息科技有限公司 | Ruff OS Internet of Things operating systems applied to built-in application program |
| CN108182066A (en) * | 2017-12-22 | 2018-06-19 | 天津七二通信广播股份有限公司 | One kind is based on embedded system locomotive platform kernel implementation method |
| CN109828786A (en) * | 2017-11-23 | 2019-05-31 | 中标软件有限公司 | Automated tool based on code-level support sw _64 architecture |
| CN109857441A (en) * | 2019-02-19 | 2019-06-07 | 深圳供电局有限公司 | A kind of method that mobile terminal and its APP software package cloud update |
| CN111045714A (en) * | 2019-12-19 | 2020-04-21 | 歌尔股份有限公司 | Firmware updating method and device, earphone and computer readable storage medium |
| CN111722875A (en) * | 2020-05-19 | 2020-09-29 | 上海中科网威信息技术有限公司 | Method for rapidly transplanting and compiling open source program by Shenwei platform |
| CN112083948A (en) * | 2020-08-28 | 2020-12-15 | 广州九尾信息科技有限公司 | Automatic construction and deployment method and tool based on data configuration |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9158573B2 (en) * | 2013-12-12 | 2015-10-13 | International Business Machines Corporation | Dynamic predictor for coalescing memory transactions |
| US9430223B2 (en) * | 2014-09-25 | 2016-08-30 | International Business Machines Corporation | Live operating system update mechanisms |
-
2021
- 2021-02-08 CN CN202110178098.XA patent/CN112860316B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103608778A (en) * | 2011-05-13 | 2014-02-26 | 安蒂克斯实验室有限公司 | Method of distributing multi-user software application |
| CN107992291A (en) * | 2017-11-16 | 2018-05-04 | 上海南潮信息科技有限公司 | Ruff OS Internet of Things operating systems applied to built-in application program |
| CN109828786A (en) * | 2017-11-23 | 2019-05-31 | 中标软件有限公司 | Automated tool based on code-level support sw _64 architecture |
| CN108182066A (en) * | 2017-12-22 | 2018-06-19 | 天津七二通信广播股份有限公司 | One kind is based on embedded system locomotive platform kernel implementation method |
| CN109857441A (en) * | 2019-02-19 | 2019-06-07 | 深圳供电局有限公司 | A kind of method that mobile terminal and its APP software package cloud update |
| CN111045714A (en) * | 2019-12-19 | 2020-04-21 | 歌尔股份有限公司 | Firmware updating method and device, earphone and computer readable storage medium |
| CN111722875A (en) * | 2020-05-19 | 2020-09-29 | 上海中科网威信息技术有限公司 | Method for rapidly transplanting and compiling open source program by Shenwei platform |
| CN112083948A (en) * | 2020-08-28 | 2020-12-15 | 广州九尾信息科技有限公司 | Automatic construction and deployment method and tool based on data configuration |
Non-Patent Citations (2)
| Title |
|---|
| "Software Configuration Engineering in Practice Interviews, Survey, and Systematic Literature Review";Mohammed SAYAGH;《IEEE Transactions on Software Engineering》;第46卷(第6期);第646-673页 * |
| "航天嵌入式Linux实时性能优化研究";刘宇帅;《航天控制》;第36卷(第03期);第57-62+78页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112860316A (en) | 2021-05-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20200293291A1 (en) | Source code generation from web-sourced snippets | |
| CN109343854B (en) | Intelligent automatic compiling method and system based on zynq system | |
| US20130097593A1 (en) | Computer-Guided Holistic Optimization of MapReduce Applications | |
| US20020198868A1 (en) | System and method for specification tracking in a Java compatibility testing environment | |
| CN110554954B (en) | Test case selection method combining static dependency and dynamic execution rule | |
| CN111950212A (en) | Efficient multi-mode verification platform and method | |
| CN109032631B (en) | Application program patch package obtaining method and device, computer equipment and storage medium | |
| US20070061641A1 (en) | Apparatus and method for generating test driver | |
| CN111597243A (en) | Data warehouse-based abstract data loading method and system | |
| CN112860316B (en) | Kernel and BSP transplanting method of openEular open source system | |
| CN110543427A (en) | Test case storage method and device, electronic equipment and storage medium | |
| CN101944061B (en) | Method and device for debugging codes | |
| Hey | INDIRECT: Intent-driven requirements-to-code traceability | |
| CN111596970B (en) | Method, device, equipment and storage medium for dynamic library delay loading | |
| CN111061486B (en) | Android application program increment method | |
| CN110633084B (en) | Transcoding derivation method and device based on single sample | |
| US20080040705A1 (en) | Method for building software project | |
| CN114924767A (en) | Kernel data type dynamic expansion hot patch method based on alignment holes | |
| CN113434430A (en) | SQL query statement performance detection method and device | |
| CN112464596A (en) | Regression testing method, system, equipment and readable storage medium | |
| CN111142923A (en) | Patch management method and system | |
| CN111078193A (en) | Software development method and system for data analysis system | |
| US20030003432A1 (en) | System and method for automated assertion acquisition in a Java compatibility testing environment | |
| US20120330878A1 (en) | Conventions for inferring data models | |
| CN117851270B (en) | Method and device for testing system-on-chip compiler, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |