CN107506323B

CN107506323B - Hot plug processing method and device

Info

Publication number: CN107506323B
Application number: CN201710614357.2A
Authority: CN
Inventors: 陈琪林; 何友松; 梁艳中; 罗健
Original assignee: Huawei Technologies Co Ltd
Current assignee: XFusion Digital Technologies Co Ltd
Priority date: 2017-07-25
Filing date: 2017-07-25
Publication date: 2020-03-20
Anticipated expiration: 2037-07-25
Also published as: CN107506323A

Abstract

The embodiment of the application discloses a hot plug processing method and a hot plug processing device, relates to the field of computers, and aims to respond to a plug event in time, ensure that the connection topology of hardware equipment in an operating system is consistent with the reality and improve the reliability of the operating system. The specific scheme is as follows: the framework layer receives a plug-pull event reported by the drive layer; according to the plugging event, hardware equipment is found in the first work queue, and the connection state of the hardware equipment on the OS is obtained, wherein the connection state comprises plugging or unplugging; and according to the connection state of the hardware equipment, registering the inserted hardware equipment in the second work queue to the OS or logging out the pulled hardware equipment from the OS. The method and the device are used for plug event processing.

Description

Hot plug processing method and device

Technical Field

The present application relates to the field of computers, and in particular, to a hot plug processing method and apparatus.

Background

In the application of a hardware device (e.g., a hard disk), there are many factors (e.g., plugging and unplugging a server or an array-connected hardware device based on a user requirement, or due to an influence of an environment or a cable) that cause a change in a hardware connection topology, and at this time, the hardware device generates an interrupt reporting driver layer such as a device up (phy up), a device down (phy down), a broadcast (broadcast) and the like according to the content of the hardware connection topology, and the driver layer converts the interrupt into an event and reports the event to a framework layer for processing, so as to synchronize the change in the hardware connection topology to an Operating System (OS).

In a Libsas framework OF a current Linux operating system, after detecting that a hardware device reported by a driver layer is inserted or pulled out OF a corresponding reporting event (port _ BYTES _ DMAED, or phy _ LOSS _ OF _ SIGNAL, or port _ BROADCAST _ RCVD), the libsa framework discovers the hardware device in a work queue (work queue) OF an OS, registers the hardware device to the OS, and logs out the hardware device from the OS. In addition, after the existing mechanism of the Libsas framework detects the above reported event, the corresponding event position 1 is received again, and the similar event is not processed until the corresponding event position is clear 0.

For a series of events caused by the situation that hardware equipment is frequently and quickly plugged and unplugged, the current libsas framework processing mechanism only processes the first reported event and discards part of the events, so that the connection topology of the hardware equipment in an operating system is inconsistent with the actual topology, and the operating system is abnormal. In addition, because the hardware equipment discovery time is short, and the hardware equipment registration and cancellation time is long, the workqueue cannot respond to the event reported by the driver in time due to the fact that the hardware equipment registration and cancellation which process the time is long are processed.

Disclosure of Invention

The embodiment of the application provides a hot plug processing method and device, which can respond to a plug event in time, ensure that the connection topology of hardware equipment in an operating system is consistent with the reality, and improve the reliability of the operating system.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical solutions:

in a first aspect, a hot plug processing method is provided, where the method may be applied to a framework layer in an OS, and the framework layer is configured with a first work queue and a second work queue. The method specifically comprises the following steps: receiving a plugging event reported by a driver layer; according to the plugging event, hardware equipment is found in the first work queue, and the connection state of the hardware equipment on the OS is obtained, wherein the connection state comprises plugging or unplugging; and according to the connection state of the hardware equipment, registering the inserted hardware equipment in the second work queue to the OS or logging out the pulled hardware equipment from the OS.

According to the hot plug processing method, when a plug event reported by a driver layer is received, hardware equipment is found in a first work queue to obtain the latest connection state, and the hardware equipment which is inserted into the OS is registered in a second work queue or the hardware equipment which is pulled out is logged out from the OS; and because each plugging event is dynamically processed, the connection topology of hardware equipment in the system is ensured to be consistent with the actual topology, the abnormity of the operating system is avoided, and the reliability of the operating system is improved.

The plugging event can be generated by hot plugging of a user or influence of an environmental cable and the like. Alternatively, the OS may be linux, and the framework layer may be Libsas framework. The connection state of the hardware device on the OS reflects the hardware device inserted or pulled out on the OS.

Alternatively, the first work queue may be an existing work queue in the OS, and the second work queue may be a newly configured work queue in the OS.

With reference to the first aspect, in a possible implementation manner, according to a plugging event, hardware device discovery is performed in the first work queue, and a plugging state of the hardware device is obtained, which may specifically be implemented as: generating a hardware equipment discovery event when a plugging event is received; and sending a hardware device discovery event to the first work queue for hardware device discovery in the first work queue.

With reference to the first aspect or any one of the foregoing possible implementation manners, in one possible implementation manner, according to a connection state of the hardware device, registering the inserted hardware device in the second work queue to the OS or logging out the pulled hardware device from the OS may specifically be implemented as: and if the connection state of the hardware equipment is insertion, generating a registration event, and sending the registration event to the second work queue for registering the hardware equipment inserted in the second work queue to the OS. And if the connection state of the hardware equipment is unplugged, generating a logout event, and sending the logout event to the second work queue for logging out the unplugged hardware equipment from the OS in the second work queue.

With reference to the first aspect or any one of the foregoing possible implementations, in one possible implementation, a hardware device may include: a Serial attached Small Computer system interface (SAS) hard disk, or a Serial Advanced Technology Attachment (SATA) hard disk. The plugging event may include at least one of the following events: a port _ BYTES _ DMAED event, a port _ BROADCAST _ RCVD event, a phy _ LOSS _ OF _ SIGNAL event.

With reference to the first aspect or any one of the foregoing possible implementation manners, in one possible implementation manner, the hardware device DISCOVERY EVENT may include a SAS _ DISCOVERY _ EVENT; the registration event may include: SAS _ DEVICE _ ADD event; the logoff event includes: SAS _ DEVICE _ DEL event.

In a second aspect, a hot plug processing apparatus is provided, where the apparatus is deployed in a Libsas framework in an operating system OS, and the apparatus is configured with a first work queue and a second work queue. The hot plug processing device can comprise a processor, a memory and a transceiver; the memory is used for storing computer execution instructions, and when the device runs, the processor calls the computer execution instructions stored in the memory to execute the following steps: receiving a plugging event reported by a driver layer; according to the received plugging event, discovering the hardware equipment in the first work queue, and acquiring the connection state of the hardware equipment on the OS, wherein the connection state of the hardware equipment can comprise plugging or unplugging; and according to the connection state of the hardware equipment, registering the inserted hardware equipment in the second work queue to the OS or logging out the pulled hardware equipment from the OS.

In a third aspect, a hot plug processing apparatus is provided, where the apparatus is deployed in a Libsas framework in an operating system OS, and is configured with a first work queue and a second work queue. The hot plug processing device may include: the receiving unit is used for receiving the plugging event reported by the driving layer; the discovery unit is used for discovering the hardware equipment in the first work queue according to the plugging event received by the receiving unit and acquiring the connection state of the hardware equipment on the OS, wherein the connection state comprises plugging or unplugging; and the synchronization unit is used for registering the inserted hardware equipment in the second work queue to the OS or logging out the pulled hardware equipment from the OS according to the connection state of the hardware equipment acquired by the discovery unit.

It should be noted that, for the specific implementation of the hot plug processing apparatus provided in the second aspect or the third aspect, reference may be made to the specific implementation of the first aspect, and details are not repeated here. Therefore, the hot plug processing device provided by the second aspect or the third aspect can achieve the same effect as the hot plug processing method provided by the first aspect.

In a fourth aspect, an embodiment of the present application provides a hot plug processing apparatus, where the hot plug processing apparatus may implement corresponding functions in the foregoing method example of the first aspect. The function can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software comprises one or more modules corresponding to the functions.

With reference to the fourth aspect, in a possible implementation manner, the structure of the hot plug processing apparatus includes a processor and a transceiver, where the processor is configured to support the hot plug processing apparatus to execute corresponding functions in the foregoing method. The transceiver is used for supporting the communication between the hot plug processing device and other network elements. The hot plug processing device may also include a memory, coupled to the processor, that stores program instructions and data necessary for the hot plug processing device.

In a fifth aspect, an embodiment of the present application provides a computer storage medium for storing computer software instructions for performing the functions of the method example of the first aspect, which includes a program designed to execute the first aspect.

The solution provided in the fourth aspect or the fifth aspect is used to implement the hot plug processing method provided in the first aspect, and therefore, the same beneficial effects as those of the first aspect may be achieved, and details are not repeated here.

Drawings

Fig. 1 is a schematic structural diagram of a server architecture provided in the prior art;

FIG. 1a is a schematic diagram of another server architecture provided in the prior art;

FIG. 1b is a schematic diagram of another server architecture provided in the prior art;

fig. 2 is a schematic structural diagram of a plug processing apparatus according to an embodiment of the present disclosure;

fig. 3 is a schematic flowchart of a plug processing method according to an embodiment of the present application;

fig. 4 is a schematic flowchart of another plug processing method according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of another plug processing apparatus according to an embodiment of the present disclosure;

fig. 6 is a schematic structural diagram of another plug processing apparatus according to an embodiment of the present disclosure.

Detailed Description

Currently, when the connection topology of the hardware device of the operating system changes, when the framework layer of the operating system receives a plug event reported by the driver layer, discovery, registration or logout of the hardware device is executed in a work queue according to whether the event is set, the processing efficiency and the time consumption are long, so that the connection topology change of the hardware device cannot be responded to in time, and the event setting processing mechanism causes discarding of part of the events, so that the operating system is abnormal, and the hardware connection synchronized into the operating system is inconsistent with the actual hardware connection.

Based on this, the basic principle of this application is: and configuring one work queue in an operating system framework layer for discovering the hardware equipment after receiving a plugging event, and configuring the other work queue for registering or logging off the hardware equipment. Therefore, the multi-working queue mode improves the event processing efficiency and responds to the plugging event in time; in addition, each plugging event is processed, the connection of hardware equipment synchronized to the operating system is consistent with the actual connection, the abnormity of the operating system is avoided, and the reliability of the operating system is improved.

The plug-in processing method provided by the embodiment of the application is applied to the architecture of the server 10 shown in fig. 1. As shown in fig. 1, the operating system 101 is deployed on the server 10, and the operating system 101 includes a driver layer 1011 and a framework layer 1012. The server 10 further includes a hardware layer 102, where the hardware layer 102 is connected to the operating system 101, and supports the server 10 to implement its storage function. The devices deployed in hardware layer 102 are referred to as hardware devices on operating system 101. The plug-in processing method provided by the embodiment of the application is applied to the framework layer 1012 in the operating system 101.

Optionally, the hardware layer 102 may be connected to the operating system 101 through an Input/Output (I/0) port of the operating system.

Illustratively, the I/O port may be a Host Bus Adapter (HBA). An HBA is a circuit board and/or integrated circuit adapter that provides I/O processing and physical connections between a server and a storage device

Illustratively, the hardware layer 102 may be a disk enclosure, and at least one disk or hard disk may be connected to the disk enclosure through a disk slot.

As shown in fig. 1a, the hardware layer 102 is taken as a disk frame, the disk frame includes a plurality of disks, and the disk frame is connected to the operating system 101 through the HBA, for example, which illustrates another architecture of the server 10.

Alternatively, in a large server architecture, in order to extend the storage capability of the server, an expansion device may be deployed in the hardware layer 102, and a next hardware device may be connected to the expansion device.

As shown in fig. 1b, another architecture of the server 10 is illustrated. In fig. 1b, the hardware layer 102 is a disk frame, where the disk frame includes a plurality of disks, and the disk frame is connected to the operating system 101 through the HBA, and is configured with an expansion device, and is connected to a next-level disk frame, and a disk slot disposed in the next-level disk frame may be inserted into a hardware device.

In the server 10 architecture shown in fig. 1, fig. 1a or fig. 1b, when a hardware device on the hardware layer 102 connected to the operating system 101 is plugged in or pulled out, the hardware layer 102 generates a hardware interrupt and reports the hardware interrupt to the driver layer 1011. After receiving the hardware interrupt reported by the hardware layer 102, the driver layer 1011 converts the hardware interrupt into a driver event (i.e., a plug-and-play event), and reports the driver event to the framework layer 1102. When receiving a plugging event, the framework layer 1102 first discovers a hardware device, then registers the plugged-in hardware device or logs out the plugged-out hardware device, and synchronizes the plugging-in or unplugging-out of the hardware device to the operating system 101.

It should be noted that, the embodiments of the present application are not specifically limited with respect to the types of hardware devices deployed in the server 10, the operating system 101, and the hardware layer 102. Illustratively, the operating system 101 may be a linux operating system and the framework layer 1012 may be a Libsas framework.

It should be noted that fig. 1, fig. 1a, or fig. 1b only illustrate the architecture of the server 10 related to the present application, and the internal structure of the operating system 101, it is understood that other parts may also be included in the server 10 and the operating system 101, and are not shown one by one here.

The terms "first" and "second," and the like, in the description and in the claims of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular order of the objects. For example, the first base station and the second base station, etc. are for distinguishing different base stations, and are not for describing a specific order of the devices.

In the embodiments of the present application, words such as "exemplary" or "for example" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present relevant concepts in a concrete fashion for ease of understanding.

Embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

In one aspect, an embodiment of the present application provides a plug processing device, and fig. 2 is a schematic structural diagram of a plug processing device 20 according to various embodiments of the present application. The plug processing device 20 may be deployed in a framework layer 1012 in the operating system 101 in the server 10 shown in fig. 1 or fig. 1a or fig. 1 b. The plug processing device 20 is provided with a first work queue and a second work queue.

As shown in fig. 2, the plug processing device 20 may include: a processor 201, a memory 202, a communication bus 203, and a transceiver 204.

The memory 202 is configured to store program codes and transmit the program codes to the processor 201, so that the processor 201 executes the program codes to implement various functions of the plugging processing device 20. The memory 202 may be a volatile memory (volatile memory), such as a random-access memory (RAM); or a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a Hard Disk Drive (HDD) or a solid-state drive (SSD); or a combination of the above types of memories.

The processor 201 is a control center of the plug processing device 20, and may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, for example: one or more microprocessors (digital signal processors, DSPs), or one or more Field Programmable Gate Arrays (FPGAs). The processor 201 may implement various functions of the plugging processing device 20 by running or executing program codes stored in the memory 202 and calling data stored in the memory 202.

The communication bus 203 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus 203 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 2, but it is not intended that there be only one bus or one type of bus.

The transceiver 204 may be a communication port of the plug processing apparatus 20 for communication interaction with other network devices.

Wherein, the processor 201 is specifically configured to:

receiving a plugging event reported by a driver layer through a transceiver 204; according to the plugging event, discovering hardware equipment in the first work queue, and acquiring the connection state of the hardware equipment, wherein the connection state comprises plugging or unplugging; and according to the connection state of the hardware equipment, registering the inserted hardware equipment in the second work queue to the OS or logging out the pulled hardware equipment from the OS.

On the other hand, an embodiment of the present application provides a hot plug processing method, which is applied to a framework layer in an OS, where the framework layer is configured with a first work queue and a second work queue.

It should be noted that, for a specific process of configuring a work queue in a framework layer, the embodiment of the present application is not specifically limited to this, and the operation may be performed according to actual requirements, as long as the framework layer configures a first work queue and a second work queue, which both belong to the solutions described in the embodiment of the present application.

As shown in fig. 3, the method may include:

s301, the framework layer receives the plugging event reported by the driver layer.

Alternatively, the hardware devices may include, but are not limited to: SAS hard disks, or SATA hard disks. Of course, the hardware device may also be other hardware devices connected to the operating system, and the type of the hardware device is not specifically limited in the embodiment of the present application, and all devices deployed in the hardware layer may be referred to as the hardware device referred to in the present application.

Specifically, the plugging event reported by the driver layer in S301 is converted from a hardware interrupt reported by the hardware layer when the hardware layer is plugged in or unplugged from the hardware device. When one hardware device is loosened due to hot plug of a user or environmental cables, the hardware layer can generate corresponding hardware interruption and report the hardware interruption to the driving layer, and the driving layer reports the hardware interruption to the framework layer after converting the hardware interruption into a plug event.

For example, the hardware interrupt reported by the hardware layer to the driver layer may include, but is not limited to, at least one of the following interrupts: phy up, phy down, brooadcast.

It should be noted that, depending on a network topology of a hardware device connected to an operating system, a generated hardware interrupt or a situation of generating the hardware interrupt may also be different, and this is not specifically limited in this embodiment of the application, and is not illustrated.

After receiving the hardware interrupt reported by the hardware layer, the driver layer converts the hardware interrupt into a corresponding plugging event for sending to the framework layer. Optionally, the plugging event may include at least one of the following events: a port _ BYTES _ DMAED event, a port _ BROADCAST _ RCVD event, a phy _ LOSS _ OF _ SIGNAL event. It should be noted that, in the embodiment of the present application, names of the plugging events are not specifically limited, and all events obtained by hardware interrupt conversion caused by plugging and unplugging may be understood as the plugging events described in the present application.

For example, the port _ BYTES _ DMAED event may be translated from phy up hardware interrupts, the port _ BROADCAST _ RCVD event may be translated from BROADCAST hardware interrupts, and the phy _ LOSS _ OF _ SIGNAL event may be translated from phy down hardware interrupts.

S302, the framework layer discovers the hardware equipment in the first work queue according to the received plugging event, and obtains the connection state of the hardware equipment on the OS.

Wherein the connection state comprises insertion or extraction.

Specifically, as to the process of discovering the hardware device, this embodiment of the present application is not particularly limited in this respect. All the processes of acquiring the connection state of the hardware device can be understood as the hardware device discovery described in the present application.

Alternatively, the connection state of the hardware device may reflect the topology of the hardware device connected on the OS. For example, the connection state of the hardware device includes which location on the OS is currently connected with the hardware device and which location is not connected with the hardware device. By comparing the latest connection state of the hardware device with the previous connection state, the identification, and/or connection location, of the newly inserted hardware device or the pulled-out hardware device can be determined.

Alternatively, the connection state of the hardware device may reflect a change in the topology of the hardware device connected on the OS. The connection status of a hardware device may include an identification of the newly inserted or removed hardware device, and/or a connection location. The identifier of the newly inserted or pulled hardware device and/or the connection position may be used to uniquely determine a hardware device in the OS hardware device connection topology, so as to facilitate subsequent hardware device registration or logout.

The identifier of the hardware device is information for uniquely identifying the hardware device, and the content and the form of the identifier of the hardware device are not specifically limited in the embodiment of the present application and can be configured according to actual requirements. The connection position of the hardware device refers to an identifier of a port connected in the OS hardware layer of the hardware device, and the content and the form of the connection position of the hardware device are not specifically limited in the embodiments of the present application, and may be configured according to actual requirements.

For example, in S302, the framework layer performs hardware device discovery in the first work queue, and determines whether a plugging event is generated due to plugging in a hardware device or due to unplugging the hardware device. When the plugging event is judged to be due to the fact that the hardware equipment is plugged, acquiring that the connection state of the hardware equipment is plugged; and when the plugging event is judged to be due to the fact that the hardware equipment is pulled out, acquiring that the connection state of the hardware equipment is pulled out.

Further optionally, in S302, the identifier of the newly inserted or pulled hardware device and/or the connection location may also be obtained through hardware device discovery.

For example, when the hardware device discovery is performed in S302, the topology of the hardware device at the current time is obtained, and compared with the topology of the hardware device at the previous time, the identifier and/or the connection location of the newly plugged or unplugged hardware device are obtained.

Specifically, in the implementation of an actual solution, the process of S302 is not specifically limited in the embodiment of the present application, and may be configured according to actual requirements, and all of the contents of the solution described in the embodiment of the present application belong to as long as only hardware device discovery is performed in one work queue.

For example, an embodiment of the present application provides a specific process for executing S302, which may include: generating a hardware equipment discovery event when a plugging event is received; and sending a hardware equipment discovery event to the first work queue, wherein the hardware equipment discovery event is used for discovering hardware equipment in the first work queue and acquiring the plugging and unplugging state of the hardware equipment.

Illustratively, the hardware device DISCOVERY EVENT may include a SAS _ discover _ EVENT. Of course, in practical applications, names of events may be configured according to actual requirements, and this is not specifically limited in the embodiment of the present application.

Alternatively, the first work queue may be a work queue configured for an existing architecture in the OS.

And S303, the framework layer registers the inserted hardware equipment in the second work queue to the OS or logs out the pulled hardware equipment from the OS according to the connection state of the hardware equipment.

Specifically, if it is determined in S302 that a newly inserted hardware device is present, the connection state of the hardware device on the OS is obtained as an insertion in S302, and in S303, an operation of registering the newly inserted hardware device to the OS is performed in the second work queue; if it is determined in S302 that there is a newly pulled-out hardware device, the connection state of the hardware device on the OS is pulled out in S302, and an operation of registering the pulled-out hardware device to the OS is performed in the second work queue in S303.

Further optionally, S303 may be specifically implemented as: if the connection state of the hardware equipment on the OS is insertion, generating a registration event, sending the registration event to a second work queue, and registering the hardware equipment inserted in the second work queue to the OS; and if the connection state of the hardware equipment on the OS is unplugged, generating a logout event, and sending the logout event to the second work queue for logging out the unplugged hardware equipment in the second work queue from the OS.

Illustratively, registration events may include: SAS _ DEVICE _ ADD event; the logoff event may include: SAS _ DEVICE _ DEL event. Of course, in practical applications, names of events may be configured according to actual requirements, and this is not specifically limited in the embodiment of the present application.

Optionally, the second work queue may be a newly added work queue configured based on an original architecture in the OS.

It should be noted that, for the process of registering or deregistering the hardware device in the OS, this embodiment of the present application is not specifically limited to this, and is not described in detail. Any method for registering or deregistering a hardware device in an OS can be applied to this.

It should be further noted that, for each plugging event, the processes in S301 to S303 may be respectively performed, and the specific processes are the same, which is not described in detail in this embodiment of the present application. In the implementation process of the embodiment of the application, one hardware device can be uniquely identified by the identifier or the connection position of the hardware device, and specific applications are not repeated.

According to the hot plug processing method, when a plug event reported by a driver is received, hardware equipment is found in the first work queue, and the hardware equipment is registered to the OS or is logged out from the OS in the second queue; and because each plugging event is dynamically processed, the connection topology of hardware equipment in the system is ensured to be consistent with the actual topology, the abnormity of the operating system is avoided, and the reliability of the operating system is improved.

For example, fig. 4 illustrates a flowchart of a hot plug processing method provided in an embodiment of the present application. If a hardware device of a plurality of hardware devices connected with the OS is hot-plugged by a user, a hardware layer may generate a hardware interrupt. The hardware interrupt is reported to the driver layer by the hardware layer. The driver layer converts the hardware interrupt into a corresponding plugging event. And the driver layer reports the plugging event to the framework layer. The framework layer performs hardware device discovery in a first work queue. After the hardware equipment is found, if the hardware equipment is inserted, the hardware equipment inserted in the second work queue by the framework layer is registered to the OS; and if the hardware equipment is pulled out, the hardware equipment pulled out in the second work queue by the framework layer is registered to the OS.

The above description mainly introduces the scheme provided in the embodiment of the present application from the perspective of the working process of the hot plug processing apparatus. It is understood that the hot plug processing device comprises hardware structures and/or software modules for executing the functions in order to realize the functions. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, functional modules may be divided by using different method apparatuses according to the method example, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, in the embodiment of the present application, the division of the module is schematic, and is only one logic function division, and there may be another division manner in actual implementation.

Fig. 5 is a schematic diagram illustrating a possible structure of the hot plug processing apparatus according to the above embodiment, in a case where each functional module is divided according to each function. The hot plug processing device 50 may include: a receiving unit 501, a discovery unit 502 and a synchronization unit 503. The receiving unit 501 is used to support the hot plug processing device 50 to execute the process S301 in fig. 3; the discovery unit 502 is configured to support the hot plug processing device 50 to execute the process S302 in fig. 3; the synchronization unit 503 is used to support the hot plug processing device 5 to execute the process S303 in fig. 3. All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.

In the case of an integrated unit, fig. 6 shows a schematic diagram of a possible structure of the hot plug processing device according to the above embodiment. The hot plug processing device 60 may include: a processing module 601 and a communication module 602. The processing module 601 is used for controlling and managing actions of the hot plug processing device. For example, the processing module 601 is used to support the hot plug processing device 60 to execute the process S301 in fig. 3 through the communication module 602; the processing module 601 is used to support the hot plug processing device 60 to execute the processes S302 and S303 in fig. 3. The communication module 602 is used to support communication between the hot plug processing device 60 and other network entities. The hot plug processing device 60 may further comprise a storage module 603 for storing program codes and data of the hot plug processing device 60.

The processing module 601 may be the processor 201 in the physical structure of the hot plug processing device 20 shown in fig. 2, and may be a processor or a controller. For example, it may be a CPU, general purpose processor, DSP, ASIC, FPGA or other programmable logic device, transistor logic device, hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. The processor 601 may also be a combination of computing functions, e.g., comprising one or more microprocessors, DSPs and microprocessors, and the like. The communication module 602 may be the transceiver 204 in the physical structure of the hot plug processing device 20 shown in fig. 2, and the communication module 202 may be a communication port, or may be a transceiving port or a communication interface, etc. The storage module 603 may be the memory 202 in the physical structure of the hot plug processing device 20 shown in fig. 2.

When the processing module 601 is a processor, the communication module 602 is a transceiver, and the storage module 603 is a memory, the hot plug processing device 60 according to fig. 6 of the present application may be the hot plug processing device 20 shown in fig. 2.

As mentioned above, the hot plug processing device 50 or 60 provided in the embodiments of the present application may be used to implement the method implemented in the embodiments of the present application, and for convenience of description, only the portion related to the embodiments of the present application is shown, and details of the technology are not disclosed, please refer to the embodiments of the present application.

Through the above description of the embodiments, it is clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical functional division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another device, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may be one physical unit or a plurality of physical units, that is, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present invention may be essentially or partially contributed to by the prior art, or all or part of the technical solution may be embodied in the form of a software product, where the software product is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only an embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions within the technical scope of the present invention are intended to be covered by the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.

Claims

1. A hot plug processing method is characterized in that the method is applied to a framework layer in an Operating System (OS), and the framework layer is configured with a first work queue and a second work queue; the method comprises the following steps:

receiving a plugging event reported by a driver layer;

according to the plugging event, hardware equipment is found in the first work queue, and the connection state of the hardware equipment on the OS is obtained, wherein the connection state comprises plugging or unplugging;

according to the connection state of the hardware equipment, registering the inserted hardware equipment in the second work queue to the OS or logging out the pulled hardware equipment from the OS;

wherein, according to the connection state of the hardware device, registering the hardware device inserted into the second work queue to the OS or logging out the hardware device pulled out from the OS includes: if the connection state of the hardware equipment is insertion, generating a registration event, sending the registration event to the second work queue, and registering the hardware equipment inserted in the second work queue to the OS; and if the connection state of the hardware equipment is unplugged, generating a logout event, and sending the logout event to the second work queue for logging out the hardware equipment unplugged from the OS in the second work queue.

2. The method according to claim 1, wherein the discovering the hardware device in the first work queue according to the plugging event to obtain a plugging state of the hardware device includes:

generating a hardware equipment discovery event when the plugging event is received;

and sending the hardware equipment discovery event to the first work queue for hardware equipment discovery in the first work queue.

3. The method according to any one of claims 1 to 2,

the hardware device includes: SAS serial small computer system interface hard disk, or SATA serial advanced technology attachment hard disk;

the plugging event comprises at least one of the following events: a port _ BYTES _ DMAED event, a port _ BROADCAST _ RCVD event, a phy _ LOSS _ OF _ SIGNAL event.

4. The method of claim 1,

the hardware device DISCOVERY EVENT comprises a SAS _ discover _ EVENT;

the registration event includes: SAS _ DEVICE _ ADD event;

the logoff event includes: SAS _ DEVICE _ DEL event.

5. The method of claim 3,

the hardware device DISCOVERY EVENT comprises a SAS _ discover _ EVENT;

the registration event includes: SAS _ DEVICE _ ADD event;

the logoff event includes: SAS _ DEVICE _ DEL event.

6. The device is characterized in that the device is deployed in a framework layer in an Operating System (OS), and a first work queue and a second work queue are configured in the device; the apparatus comprises a processor, a memory, and a transceiver; the memory is used for storing computer execution instructions, and when the device runs, the processor calls the computer execution instructions stored in the memory to execute the following steps:

receiving a plugging event reported by a driver layer;

wherein the processor is specifically configured to: if the connection state of the hardware equipment is insertion, generating a registration event, sending the registration event to the second work queue, and registering the hardware equipment inserted in the second work queue to the OS; and if the connection state of the hardware equipment is unplugged, generating a logout event, and sending the logout event to the second work queue for logging out the hardware equipment unplugged from the OS in the second work queue.

7. The apparatus of claim 6, wherein the processor is specifically configured to:

8. The apparatus according to any one of claims 6 to 7,

9. The apparatus of claim 6,

the hardware device DISCOVERY EVENT comprises a SAS _ discover _ EVENT;

the registration event includes: SAS _ DEVICE _ ADD event;

the logoff event includes: SAS _ DEVICE _ DEL event.

10. The apparatus of claim 8,

the hardware device DISCOVERY EVENT comprises a SAS _ discover _ EVENT;

the registration event includes: SAS _ DEVICE _ ADD event;

the logoff event includes: SAS _ DEVICE _ DEL event.

11. The device is characterized in that the device is deployed in a framework layer in an Operating System (OS), and a first work queue and a second work queue are configured in the device; the device comprises:

the receiving unit is used for receiving the plugging event reported by the driving layer;

a discovery unit, configured to perform hardware device discovery in the first work queue according to the plug event received by the receiving unit, and acquire a connection state of a hardware device on the OS, where the connection state includes insertion or extraction;

a synchronization unit, configured to register, according to the connection state of the hardware device obtained by the discovery unit, the hardware device inserted into the second work queue into the OS or log out the pulled hardware device from the OS; the method specifically comprises the following steps: if the connection state of the hardware equipment is insertion, generating a registration event, sending the registration event to the second work queue, and registering the hardware equipment inserted in the second work queue to the OS; and if the connection state of the hardware equipment is unplugged, generating a logout event, and sending the logout event to the second work queue for logging out the hardware equipment unplugged from the OS in the second work queue.

12. A computer-readable storage medium, comprising instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 1-5.