Solution For Gadget

        endian or endianness refers to the ordering of individually addressable sub-components within the representation of a larger data item as stored in external memory. The most common cases refer to how bytes are ordered within a single 16-, 32-, or 64-bit word, and endianness is then the same as byte order. The usual contrast is whether the most significant or least significant byte is ordered first.

Consider a memory location occupied by an Integer variable of 4-bytes:

Little Endian : In this the lower-order byte of the number is stored in memory at the lowest address, and the high-order byte at the highest address. For example, a 4 byte Integer

will be arranged in memory as follows:

Base Address+0 -> Byte0
Base Address+1 -> Byte1
Base Address+2 -> Byte2
Base Address+3 -> Byte3

Example: Intel processors (those used in PCs) use "Little Endian" byte order.

Big Endian: In this the high-order byte of the number is stored in memory at the lowest address, and the low-order byte at the highest address. The same 4 byte integer would be stored as:

Base Address+0 -> Byte3
Base Address+1 -> Byte2
Base Address+2 -> Byte1
Base Address+3 -> Byte0

Example: Motorola processors (those used in Macs) use "Big Endian" byte order.

The Linux Device model is built around the concept of busses, devices and drivers. All devices in the system are connected to a bus of some kind. The bus does not have to be a real one; busses primarily exist to gather similar devices together and coordinate initialization, shutdown and power management.

When a device in the system is found to match a driver, they are bound together. The specifics about how to match devices and drivers are bus-specific. The PCI bus, for example, compares the PCI Device ID of each device against a table of supported PCI IDs provided by the driver. The platform bus, on the other hand, simply compares the name of each device against the name of each driver; if they are the same, the device matches the driver.

Binding a device to a driver involves calling the driver’s probe() function passing a pointer to the device as a parameter. From this point on, it’s the responsibility of the driver to get the device properly initialized and register it with any appropriate subsystems.

Devices that can be hot-plugged must be un-bound from the driver when they are
removed from the system. This involves calling the driver’s remove() function passing a pointer to the device as a parameter. This also happens if the driver is a dynamically loadable module and the module is unloaded. All device driver callbacks, including probe() and remove(), must follow the return
value.