Linux Driver Interview Topics summary

http://blog.csdn.net/blueice8601/article/details/7666427

1. Linux Driver classification

2. Signal volume and Spin lock

3, platform bus equipment and bus equipment how to write

4. The difference between Kmalloc and Vmalloc

5, the level of module_init

6. Add Driver

7. IIC principle, bus frame, device writing method, i2c_msg

8, Kernel panic

9, USB bus, USB transmission type, URB, etc.

10. Android Boot Process

11. Android Init parsing init.rc

12. Synchronization and mutual exclusion

Answer:

1, http://baike.baidu.com/view/5363967.htm

Linux device-driven classification (1) character device. 　　(2) block device. 　　(3) Network equipment. A character device is a device that must be accessed in serial order, such as a touchscreen, a tape drive, a mouse, and so on. Block devices can be accessed in any order, in blocks, such as hard disks, floppy drives, and so on. Character devices are not quickly buffered by the system, and block devices are quickly buffered by the system. However, character devices and block devices do not have significant boundaries, such as for Flash devices, which conform to the features of block devices, but we can still use it as a character device to access. The system supports caching of transmitted and received data, provides traffic control mechanisms, and provides support for multiple protocols.

2, http://www.cnblogs.com/linxinshuo/archive/2009/12/08/1619771.html

Spin lock

Spin locks are a kind of lock that is introduced to prevent multiprocessor concurrency, and it is applied to interrupt processing and other parts. For a single processor, the prevention of concurrency in interrupt processing can be simplified by turning off interrupts without the need for a spin lock.

A spin lock can only be held by a single kernel task, and if a kernel task attempts to request a spin lock that has already been contended (it has been held), then the task will always be busy-rotating-waiting for the lock to be re-usable. If the lock is not contended, the kernel task requesting it can get it immediately and continue. A spin lock can prevent more than one kernel task from entering the critical section at any time, so this lock effectively avoids competing for shared resources on multi-processor kernel tasks that run concurrently.

In fact, the spin lock is designed to be a lightweight lock in a short period of time. A competing spin lock causes the thread that requested it to spin (particularly wasting processor time) during the time the lock is re-usable, so the spin lock should not be held for too long. If it takes a long time to lock, it is best to use the semaphore. However, spin locks save the overhead of context switching.

The basic form of spin lock is as follows:

Spin_lock (&mr_lock);

Critical section

Spin_unlock (&mr_lock);

Since spin locks can only be held at most one kernel task at a time, only one thread at a time is allowed to exist in the critical section. This is a good way to satisfy the locking service required for symmetric multi-processing machines. On a single processor, a spin lock is simply a switch that sets the kernel preemption. If the kernel preemption does not exist, then the spin lock is completely stripped out of the kernel at compile time.

Simply put, the spin lock is primarily used in the kernel to prevent concurrent access to critical sections in multiple processors, preventing the competition from kernel preemption. In addition, the spin lock does not allow task sleep (the task that holds the spin lock causes a self-deadlock-because sleep can cause the kernel task that holds the lock to be re-dispatched, and then reapply for the lock it has held), it can be used in the context of the interrupt.

Deadlock: Suppose you have one or more kernel tasks and one or more resources, each of which is waiting for one of the resources, but all of the resources are already occupied. This occurs when all kernel tasks are waiting for each other, but they never release the resources already in place, so no kernel task can get the resources needed to continue running, which means the deadlock has occurred. Self-death is to say that they have a certain resources, and then apply for their own resources, it is obviously impossible to obtain the resources, therefore, self-binding hands and feet. This can happen with recursion using a spin lock.

Signal Volume

The semaphore is a sleep lock. If there is a task trying to get a semaphore that has been held, the semaphore pushes it into the waiting queue and then lets it sleep. The processor then gets free to execute other code. When the semaphore-holding process releases the semaphore, a task in the waiting queue will be awakened, thereby obtaining the semaphore.

The sleep characteristics of the semaphore, which makes the semaphore suitable for long-time hold of the lock, can only be used in the context of the process, because the interrupt context is not scheduled, and when the code holds the semaphore, it can no longer hold the spin lock.

The basic use of semaphores is:

Static Declare_mutex (Mr_sem);//declaring mutually exclusive semaphores

if (down_interruptible (&mr_sem))

Sleep can be interrupted when the signal comes, the task of sleep is awakened

Critical section

Up (&mr_sem);

Signal volume and Spin lock difference

In the strict sense, the signal volume and the spin lock belong to different levels of mutually exclusive means, the former realization depends on the latter.

Note the following principles:

If the code needs to sleep-this is often the case when synchronizing with user space-the use of semaphores is the only option. Because it is not limited by sleep, the use of semaphores is generally simpler. If you need to choose between spin locks and semaphores, it depends on the length of time the lock is held. Ideally, all locks should be held as short as possible, but if the lock is held for a longer period of time, the use of the semaphore is a better choice. In addition, the semaphore differs from the spin lock, which does not turn off kernel preemption, so the code holding the semaphore can be preempted. This means that the semaphore does not negatively affect the scheduling response time.

Spin lock to signal volume

Lock-in method for demand recommendation

Low overhead lock priority using spin lock

Short-term lock priority with spin lock

Long-term lock priority use of semaphores

Lock using spin lock in interrupt context

Holding a lock is a need to sleep, dispatch the use of the semaphore

3, http://www.cnblogs.com/noaming1900/archive/2010/10/26/1861177.html

http://blog.chinaunix.net/space.php?uid=11909535&do=blog&id=2801676

http://slhieanng.blog.163.com/blog/static/1932833562011731982291/

4, http://blog.163.com/[email protected]/blog/static/109968875201241961116110/

Kmalloc () and Vmalloc () Introduction
kmalloc ()
for requesting smaller, contiguous physical memory
1. Allocation in bytes, in <linux/slab.h>
2. void *kmalloc (size_t size, int flags) is allocated on a contiguous memory physical address, The virtual address is naturally contiguous
3. Gfp_mask flag : When to use what kind of flag? As follows:
———————————————————————————————-
Case Flags
———————————————————————————————-
Process context, can sleep Gfp_kernel
Process context, cannot sleep gfp_atomic
Interrupt handler gfp_atomic
Soft interrupt gfp_atomic
Tasklet gfp_atomic
Memory for DMA, can sleep GFP_DMA | Gfp_kernel
Memory for DMA, can not sleep GFP_DMA | Gfp_atomic
———————————————————————————————-
4. void Kfree (const void *PTR)
releases a block of memory allocated by Kmalloc ()

Vmalloc ()
Used to request a larger memory space, virtual memory is contiguous
1. allocate in bytes , in <linux/vmalloc.h>
2. void *vmalloc (unsigned long size) allocated memory virtual address on continuous, physical address discontinuous
3. In general, only hardware devices need physical address contiguous memory, because hardware devices often exist outside the MMU, do not know the virtual address, but for performance reasons, the kernel generally uses kmalloc (), and only when the need to obtain large chunks of memory to use Vmalloc (), For example, when the module is dynamically loaded into the kernel, the module is loaded into the memory allocated by Vmalloc ().
4.void Vfree (void *addr), this function can sleep and therefore cannot be called from the interrupt context.

malloc (), Vmalloc () and kmalloc () differences
[*]kmalloc and Vmalloc are allocated kernel memory, and malloc allocates the user's memory
[*]kmalloc guarantees that the distribution is physically contiguous, vmalloc guarantees continuity on the virtual address space, and malloc does not guarantee anything (this is self-guessing, not necessarily correct)
[*]kmalloc can allocate a limited size, vmalloc and malloc can allocate a relatively large size
[*] memory only needs to be physically contiguous when it is being accessed by DMA
[*]vmalloc is slower than Kmalloc

5, http://blog.163.com/[email protected]/blog/static/167563447201010221231507/

#define MODULE_INIT (x) __initcall (x);
#define __initcall (FN) Device_initcall (FN)

#define Device_initcall (FN) __define_initcall ("6", fn,6)

The level of Module_init () is 6

In the Vmlinux.lds
. Initcall.init:AT (ADDR (. initcall.init)-(0xc0000000-0x00000000)) {
__initcall_start =.;
* (. initcallearly.init) __early_initcall_end =.; * (. Initcall0.init) * (. initcall0s.init) * (. initcall1.init) * (. initcall1s.init) * (. initcall2.init) * (. Initcall2s.init ) * (. initcall3.init) * (. initcall3s.init) * (. initcall4.init) * (. initcall4s.init) * (. initcall5.init) * (. Initcall5s.init) * (. initcallrootfs.init) * (. initcall6.init) * (. initcall6s.init) * (. initcall7.init) * (. Initcall7s.init)
__initcall_end =.;
}

You can see that Initcall is divided into a total of 0~7 eight levels, indicating that when the system calls Do_initcalls () during startup, it is called according to their level order. It is known when the initialization function in Module_init in the module is called: Start_kernel ()->rest_init ()->kernel_init ()->do_basic_setup () during system startup ()- >do_initcalls ().

6.

On static loading and dynamic loading:

Static loading is automatically loaded by the kernel when the system starts, which is to compile the driver into the kernel in advance;

Dynamic loading, that is, the mode of module loading, in this way the driver in the form of modules stored in the file system, the need to dynamically load the kernel, which is mainly used in debugging, more convenient and flexible. Insmod Module.ko

7.

Http://liu1227787871.blog.163.com/blog/static/2053631972012521191287/IIC basic knowledge of the bus

http://blog.163.com/[email protected]/BLOG/STATIC/109968875201243094211492/IIC bus driver Architecture analysis

Http://liu1227787871.blog.163.com/blog/static/20536319720125333531134/IIC Driver Analysis

http://liu1227787871.blog.163.com/blog/static/2053631972012539436224/

http://liu1227787871.blog.163.com/blog/static/2053631972012531048573/

http://liu1227787871.blog.163.com/blog/static/2053631972012531620760/

8.

http://blog.51osos.com/linux/linux-kernel-panic/

There are two main types of kernel panic:

1.hard panic (i.e. AIEEE information output)
2.soft panic (i.e. oops information output)

9.

USB bus:

The USB bus belongs to a polling bus, and the host control port initializes all data transmissions. Each bus action transmits a maximum of three packets, including tokens, data, and contacts (handshake). In accordance with the principles established before transmission, at the beginning of each transfer, the host sends a USB packet describing the type, direction, USB device address and terminal number of the transmission action, which is often referred to as the token package (tokenpacket). The USB device extracts its own data from the appropriate location of the decoded packet. The data transfer direction is not from the host to the device or from the device to the host. At the beginning of the transfer, a flag packet is sent to indicate the direction of the transmission of the data, and then the sending side begins to send packets containing information or indicates that no data is being transmitted. The receiving side also sends a corresponding handshake packet to indicate whether the transmission was successful. The USB data transfer between the sending and receiving ends can be treated as a channel between the host and the port of the device. USB has a special channel a default control channel, which belongs to the message channel, the device can be started to exist, thus providing a portal for device settings, status queries and input control information.

Four types of transmission for USB bus:

1, interrupt transmission: By the out transaction and in transactions, for the keyboard, mouse and other HID device data transmission 2, bulk transmission: By the out transaction and in transaction composition, for the large-capacity data transmission, no fixed transmission rate, also does not occupy the bandwidth, when the bus is busy, USB takes precedence over other types of data transfer and temporarily stops the bulk transfer. 3, synchronous transmission: consists of out transactions and in transactions, there are two special places, first, in the synchronous transmission in and out transactions are not return packet stage; second, any packet in the packet phase is DATA0 4, control transmission: The most important is the most complex transmission, Control transmission consists of three phases (initial configuration phase, optional data stage, status information step), each stage can be regarded as a transmission, that is, the control transmission is actually composed of three transmission, used to the USB device first added to the host, the host through the control transmission to exchange information, Device address and read the device descriptor, so that the host to identify the device and install the appropriate driver, which is a concern for every USB developer.

URB:

USB Request block (USB requests block,urb) is a USB device driver used to describe the communication with the USB device, the basic carrier and core data structure, very similar to the network device driver in the SK_BUFF structure, is the USB host and device Communication "Radio wave."

Http://book.51cto.com/art/200803/66930.htm

10.

http://www.cnblogs.com/idiottiger/archive/2012/05/22/2513001.html Android boot process from power on

http://www.cnblogs.com/idiottiger/archive/2012/05/23/2513494.html Android Boot code flow 1

http://www.cnblogs.com/idiottiger/archive/2012/05/25/2516295.html Android Boot code flow 2

11.

Http://ytydyd.blog.sohu.com/136255592.html

Android Initialization language (Android init Language

The Android Init scripting language contains four types of statements:

• Actions (Actions)
• Directive (Commands)
• Service (services)
• Option (Options)

The syntax for the language includes the following conventions:

• All types of statements are row-based (line-oriented), and a statement consists of several tokens,token separated by a space character. If a token needs to contain a space character, it needs to be escaped by a C-style backslash (' \ '), or the entire token is quoted using double quotes. A backslash can also appear at the end of a line, which means that the contents of the next line still belong to the current statement.
• The line starting with ' # ' is the comment line.
• The actions (actions) and services statements implicitly represent the beginning of a new paragraph (section). All instructions (commands) and options are assigned to the most recent paragraph above. The instructions (commands) and options before the first paragraph are invalid.
• The action (actions) and service (services) have unique names. If there is a duplicate name, then the definition that appears will be ignored as an error.

Actions (Actions)

An action is a sequence of named commands (commands). Each action (actions) defines a trigger condition (trigger) that indicates when the action should be performed. When an event that matches an action's trigger occurs, the action is added to the end of a queue that is about to be executed (unless it is already in the queue).

Each action in the queue is taken out sequentially, and each instruction in the action is executed in turn. The initialization program (INIT) also needs to handle other operations (such as device creation/destruction, property settings, Process restarts) during the execution of an action's various instructions.

The form of an action definition is as follows:

On <trigger> <command> <command> <command>

Service (services)

Services are some of the programs that the initialization program needs to start, and it is possible for the initialization program to restart them after the programs have exited. Services take a service definition in the following form:

  Service <name> <pathname> [<argument>]* <option> <option> ...

Option (Options)

Options affect the timing and method of controlling the initialization program to run the service. The possible options are the following table.

Options	Description
disabled	This service would not be automatically start with its class. It must is explicitly started by name.
socket <name> <type>  <perm> [ <user> [ <group> ] ]	Create a UNIX domain socket named and pass its FD to the /dev/socket/<name> launched process. Valid <type> values include dgram and stream . and default to user group 0.
user <username>	Change to username before exec ' ing this service. currently defaults to root.
group <groupname> [ <groupname> ]*	Change to groupname before exec ' ing this service. Additional Groupnames beyond the first, which is required, was used to set Additional groups of the process (with setgroups() ). currently defaults to root.
capability [ <capability> ]+	Set Linux capability before exec ' ing this service
oneshot	Don't restart the service when it exits.
class <name>	Specify a class name for the service. All services in a named class must start and stop together. A service is considered of class "default" If one was not specified via the class option.

Trigger (Triggers)

A trigger is a string that matches a specific event that triggers the execution of the action that the trigger belongs to.

Trigger	Description
boot	This is the first trigger, occurs when Init starts (after is /init.conf loaded).
<name>=<value>	Triggers of this form occur if the property was set to the <name> specific value <value> .
device-added-<path> device-removed-<path>	Triggers of these forms occur when a device node is added or removed.
service-exited-<name>	Triggers of this form occur when the specified service exits.

Directive (Commands)

Command	Description
exec <path> [ <argument> ]*	Fork and execute a program ( <path> ). This would block until the program completes execution. Try to avoid exec. Unlike the builtin commands, it runs the risk of getting init "stuck".
export <name> <value>	Set the environment variable equal to in the <name> <value> Global Environment (which'll be inherited by all processes Star Ted after the This command is executed).
ifup <interface>	Bring the network interface <interface> online.
import <filename>	Parse an init config file, extending the current configuration.
hostname <name>	Set the host name.
class_start <serviceclass>	Start all services of the specified class if they is not already running.
class_stop <serviceclass>	Stop all services of the specified class if they is currently running.
domainname <name>	Set the domain name.
insmod <path>	Install the module at <path> .
mkdir <path>	Make a directory at <path> .
mount <type> <device> <dir> [ <mountoption> ]*	Attempt to mount the named device at the directory <dir> <device> . This could be of the form [e-mail protected] to specify a MTD block device by name.
setkey	-Currenlty undefined-
setprop <name> <value>	Set system Property <name> to <value> .
setrlimit <resource> <cur> <max>	Set the Rlimit for a resource.
start <service>	Start a service running if it is not already running.
stop <service>	Stop a service from running if it is currently running.
symlink <target> <path>	Create a symbolic link at with the <path> value <target> .
write <path> <string> [ <string> ]*	Open the file at and <path> write one or more strings to it with write (2).

Attributes (properties)

The initialization program (INIT) can modify the properties of some systems as needed.

Property	Description
init.action	Equal to the name of the action currently being executed or "" if none.
init.command	Equal to the command being executed or "" if none.
init.svc.<name>	State of a named service ("Stopped", "running", or "restarting").

Init.rc File Example

On boot  export path/sbin:/system/sbin:/system/bin  export ld_library_path/system/lib  mkdir/dev  Mkdir/proc  Mkdir/sys  Mount Tmpfs tmpfs/dev  mkdir/dev/pts  mkdir/dev/socket  mount Devpts devpts/ Dev/pts  Mount proc Proc/proc  Mount Sysfs sysfs/sys  write/proc/cpu/alignment 4  ifup lo  hostname localhost  domainname localhost  mount YAFFS2 [email protected]/system  Mount YAFFS2 [email Protected]/data  import/system/etc/init.conf  class_start defaultservice adbd/sbin/adbd  user adb  group Adbservice usbd/system/bin/usbd-r  user usbd  group USBD  socket USBD 666service zygote/ System/bin/app_process-xzygote/system/bin--zygote  socket zygote 666service runtime/system/bin/runtime  User System  Group Systemon device-added-/dev/compass  start Akmdon device-removed-/dev/compass  stop Akmdservice AKMD/SBIN/AKMD  disabled  user AKMD  Group AKMD

12, http://www.cnblogs.com/linxinshuo/archive/2009/12/09/1620413.html

Synchronization and Mutex

There are two main types of relationships between intersecting processes, synchronous and mutually exclusive. The so-called mutual exclusion, refers to the walk between different processes of a number of program fragments, when a process runs one of the program fragments, other processes can not run any of their program fragments, can only wait until the process runs out of this program fragment to run. The so-called synchronization, refers to the walk in a number of different processes between the pieces of the program, their operation must be in strict accordance with the specified sequence of operation, this order depends on the specific task to be completed.

Obviously, synchronization is a more complex mutex, and mutual exclusion is a special kind of synchronization.

That is, mutual exclusion is two threads can not run at the same time, they will repel each other, must wait for one thread to run, another to run, and synchronization can not run concurrently, but he must be in some order to run the corresponding thread (also a mutex)!

Summarize:

Mutex: Refers to a resource that allows only one visitor to access it, with uniqueness and exclusion. However, mutual exclusion cannot limit the order in which visitors access resources, that is, access is unordered.

Synchronization: Refers to the mutual exclusion of the basis (in most cases), through other mechanisms to achieve the visitor's orderly access to resources. In most cases, synchronization has been mutually exclusive, especially if all writes to the resource must be mutually exclusive. In rare cases, multiple visitors can be allowed to access resources at the same time

Linux Driver Interview Topics summary