客舍青青

k8s first commit 源码分析之 Cloudcfg

2022-10-01T09:51:30.000Z

上一次分析了api server的源码，这一次来分析 cloudcfg 的源码。

简介

cloudcfg 可以看做是 kubectl 的前身，负责与 API server 的交互，只存在于上古时代的 k8s 中，我们现在接触到的都是 kubectl 命令行工具了。该组件做的事情非常简单，就是将用户的命令行操作转化为对 API server 的 HTTP 请求。

命令行主体逻辑

从 cloudcfg 的命令行入口开始分析，命令行代码位于 cmd/apiserver/cloudcfg.go

// The flag package provides a default help printer via -h switch
var versionFlag *bool = flag.Bool("v", false, "Print the version number.")
var httpServer *string = flag.String("h", "", "The host to connect to.")
var config *string = flag.String("c", "", "Path to the config file.")
var labelQuery *string = flag.String("l", "", "Label query to use for listing")
var updatePeriod *time.Duration = flag.Duration("u", 60*time.Second, "Update interarrival in seconds")
var portSpec *string = flag.String("p", "", "The port spec, comma-separated list of :,...")
var servicePort *int = flag.Int("s", -1, "If positive, create and run a corresponding service on this port, only used with 'run'")
var authConfig *string = flag.String("auth", os.Getenv("HOME")+"/.kubernetes_auth", "Path to the auth info file.  If missing, prompt the user")

func usage() {
log.Fatal("Usage: cloudcfg -h  [-c config/file.json] [-p :,..., :  ")
}

最开始定义了 cloudcfg 命令行工具需要的所有参数。

main 函数中先从命令行中获取 method, api server 的 host，资源对象的类型以及鉴权参数。

method := flag.Arg(0)
url := *httpServer + "/api/v1beta1" + flag.Arg(1)

auth, err := cloudcfg.LoadAuthInfo(*authConfig)
if err != nil {
    log.Fatalf("Error loading auth: %#v", err)
}

再根据 method 判断是对资源的何种操作方式。

对资源的 CRUD 是通过拼接 method 和 labelQuery 作为 api server 的请求 URL 去发送 HTTP 请求，没有其他多余的逻辑。

if method == "get" || method == "list" {
    if len(*labelQuery) > 0 && method == "list" {
        url = url + "?labels=" + *labelQuery
    }
    request, err = http.NewRequest("GET", url, nil)
} else if method == "delete" {
    request, err = http.NewRequest("DELETE", url, nil)
} else if method == "create" {
    request, err = cloudcfg.RequestWithBody(*config, url, "POST")
} else if method == "update" {
    request, err = cloudcfg.RequestWithBody(*config, url, "PUT")
}

var body string
body, err = cloudcfg.DoRequest(request, auth.User, auth.Password)
if err != nil {
    log.Fatalf("Error: %#v", err)
}
fmt.Println(body)

还有对 rollingupdate 的操作和 controller 的操作，后面分别展开分析

rollingupdate操作

判断 method 为 rollingupdate 后通过 client 执行 update

else if method == "rollingupdate" {
    client := &kube_client.Client{
        Host: *httpServer,
        Auth: &auth,
    }
    cloudcfg.Update(flag.Arg(1), client, *updatePeriod)
}

具体操作是通过pkg/client/client.go中实现的 client 进行操作， client 实现了以下接口

// ClientInterface holds the methods for clients of Kubenetes, an interface to allow mock testing
type ClientInterface interface {
ListTasks(labelQuery map[string]string) (api.TaskList, error)
GetTask(name string) (api.Task, error)
DeleteTask(name string) error
CreateTask(api.Task) (api.Task, error)
UpdateTask(api.Task) (api.Task, error)

GetReplicationController(name string) (api.ReplicationController, error)
CreateReplicationController(api.ReplicationController) (api.ReplicationController, error)
UpdateReplicationController(api.ReplicationController) (api.ReplicationController, error)
DeleteReplicationController(string) error

GetService(name string) (api.Service, error)
CreateService(api.Service) (api.Service, error)
UpdateService(api.Service) (api.Service, error)
DeleteService(string) error
}

可以看到就是对 tasks，RC 和 serveice 的操作。以 create tasks 为例

// CreateTask takes the representation of a task.  Returns the server's representation of the task, and an error, if it occurs
func (client Client) CreateTask(task api.Task) (api.Task, error) {
var result api.Task
body, err := json.Marshal(task)
if err == nil {
_, err = client.rawRequest("POST", "tasks", bytes.NewBuffer(body), &result)
}
return result, err
}

可以看到同样是通过请求 api server 来完成操作的。

回到命令行的 main 函数，创建 client 后调用cloudcfg.Update(flag.Arg(1), client, *updatePeriod)

// 代码路径：pkg/cloudcfg/cloudcfg.go
// Perform a rolling update of a collection of tasks.
// 'name' points to a replication controller.
// 'client' is used for updating tasks.
// 'updatePeriod' is the time between task updates.
func Update(name string, client client.ClientInterface, updatePeriod time.Duration) error {
controller, err := client.GetReplicationController(name)
if err != nil {
return err
}
labels := controller.DesiredState.ReplicasInSet

taskList, err := client.ListTasks(labels)
if err != nil {
return err
}
for _, task := range taskList.Items {
_, err = client.UpdateTask(task)
if err != nil {
return err
}
time.Sleep(updatePeriod)
}
return nil
}

大致逻辑是通过 name 获取 RC 对象，再通过 RC 对象的期望状态获取 tasks label，再通过 task label 来 list 所有 task 后更新 task。不过笔者没太看懂这里的更新逻辑，看上去把遍历 task 的时候由原封不动传回去了，或许第一个版本还不支持滚动更新？待笔者后续完整深入看完所有组件逻辑再来补充。

controller 操作

判断 method 为 run 时，拿到 image，replicas， name 后执行 RunController

if method == "run" {
    args := flag.Args()
    if len(args) < 4 {
        log.Fatal("usage: cloudcfg -h  run   ")
    }
    image := args[1]
    replicas, err := strconv.Atoi(args[2])
    name := args[3]
    if err != nil {
        log.Fatalf("Error parsing replicas: %#v", err)
    }
    err = cloudcfg.RunController(image, name, replicas, kube_client.Client{Host: *httpServer, Auth: &auth}, *portSpec, *servicePort)
    if err != nil {
        log.Fatalf("Error: %#v", err)
    }
    return
}

进入到 cloudcfg.RunController 函数内部分析

controller := api.ReplicationController{
    JSONBase: api.JSONBase{
        ID: name,
    },
    DesiredState: api.ReplicationControllerState{
        Replicas: replicas,
        ReplicasInSet: map[string]string{
            "name": name,
        },
        TaskTemplate: api.TaskTemplate{
            DesiredState: api.TaskState{
                Manifest: api.ContainerManifest{
                    Containers: []api.Container{
                        api.Container{
                            Image: image,
                            Ports: makePorts(portSpec),
                        },
                    },
                },
            },
            Labels: map[string]string{
                "name": name,
            },
        },
    },
    Labels: map[string]string{
        "name": name,
    },
}

controllerOut, err := client.CreateReplicationController(controller)
if err != nil {
return err
}

根据外部传入的参数构造 RC 对象，然后调用 client 的 CreateReplicationController 函数，本质还是向 API Server 发起请求

data, err := yaml.Marshal(controllerOut)
if err != nil {
    return err
}
fmt.Print(string(data))

if servicePort > 0 {
    svc, err := createService(name, servicePort, client)
    if err != nil {
        return err
    }
    data, err = yaml.Marshal(svc)
    if err != nil {
        return err
    }
    fmt.Printf(string(data))
}

再根据掺入的 servicePort 创建 service

func createService(name string, port int, client client.ClientInterface) (api.Service, error) {
svc := api.Service{
JSONBase: api.JSONBase{ID: name},
Port:     port,
Labels: map[string]string{
"name": name,
},
}
svc, err := client.CreateService(svc)
return svc, err
}

同样是向 API server 发起请求。

回到 cloudcfg 命令行中，判断 method 为 stop 时执行 StopController

else if method == "stop" {
    err = cloudcfg.StopController(flag.Arg(1), kube_client.Client{Host: *httpServer, Auth: &auth})
    if err != nil {
        log.Fatalf("Error: %#v", err)
    }
    return
}

分析 cloudcfg.StopController

// StopController stops a controller named 'name' by setting replicas to zero
func StopController(name string, client client.ClientInterface) error {
controller, err := client.GetReplicationController(name)
if err != nil {
return err
}
controller.DesiredState.Replicas = 0
controllerOut, err := client.UpdateReplicationController(controller)
if err != nil {
return err
}
data, err := yaml.Marshal(controllerOut)
if err != nil {
return err
}
fmt.Print(string(data))
return nil
}

可以看到将 RC 的 Replicas 置为 0 后发送给了 API server。

Controller 的操作还有一个 rm

lse if method == "rm" {
    err = cloudcfg.DeleteController(flag.Arg(1), kube_client.Client{Host: *httpServer, Auth: &auth})
    if err != nil {
        log.Fatalf("Error: %#v", err)
    }
    return
}

cloudcfg.DeleteController 也很简单，获取当前 RC 的副本数，如果副本数不为 0 则报错退出，否则请求 API server 删除

// DeleteController deletes a replication controller named 'name', requires that the controller
// already be stopped
func DeleteController(name string, client client.ClientInterface) error {
controller, err := client.GetReplicationController(name)
if err != nil {
return err
}
if controller.DesiredState.Replicas != 0 {
return fmt.Errorf("controller has non-zero replicas (%d)", controller.DesiredState.Replicas)
}
return client.DeleteReplicationController(name)
}

我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=2td5ld5xvow0o

k8s first commit 源码分析之 API Server

2022-09-14T16:44:10.000Z

穿越回 2014 年，分析下 k8s 第一个提交的源码。

获取 first commit 源码

1
2
3

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
git checkout `git rev-list --max-parents=0 HEAD`

简介

api-server 是 k8s 的核心组件之一，用于接收 kubelet 的请求，并将请求信息保存到后端存储 etcd 中。核心功能是提供 k8s 各类资源对象的 CURD 等操作。

源码分析

从 api-server 的命令行入口开始分析，命令行代码位于 cmd/apiserver/apiserver.go

var (
port                        = flag.Uint("port", 8080, "The port to listen on.  Default 8080.")
address                     = flag.String("address", "127.0.0.1", "The address on the local server to listen to. Default 127.0.0.1")
apiPrefix                   = flag.String("api_prefix", "/api/v1beta1", "The prefix for API requests on the server. Default '/api/v1beta1'")
etcdServerList, machineList util.StringList
)

func init() {
flag.Var(&etcdServerList, "etcd_servers", "Servers for the etcd (http://ip:port), comma separated")
flag.Var(&machineList, "machines", "List of machines to schedule onto, comma separated.")
}

最开始定义了 api-server 启动所需要的相关参数，上古版本的 k8s 使用了标准库自带的 flag 库，其中 util.StringList实现了flag.Value接口。

type StringList []string

func (sl *StringList) String() string {
return fmt.Sprint(*sl)
}

func (sl *StringList) Set(value string) error {
for _, s := range strings.Split(value, ",") {
if len(s) == 0 {
return fmt.Errorf("value should not be an empty string")
}
*sl = append(*sl, s)
}
return nil
}

可以看到util.StringList用于将以逗号分割的字符串转为[]string类型。各个命令行参数含义如下:

port: api-server 监听的 port
address: api-server 监听的 ip
apiPrefix: 访问 api-server 的 URL 前缀
etcdServerList: 后端存储的 etcd 节点列表
machineList: 工作节点的列表

从 main 函数开始分析 api-server 的具体实现

var (
    taskRegistry       registry.TaskRegistry
    controllerRegistry registry.ControllerRegistry
    serviceRegistry    registry.ServiceRegistry
)

if len(etcdServerList) > 0 {
    log.Printf("Creating etcd client pointing to %v", etcdServerList)
    etcdClient := etcd.NewClient(etcdServerList)
    taskRegistry = registry.MakeEtcdRegistry(etcdClient, machineList)
    controllerRegistry = registry.MakeEtcdRegistry(etcdClient, machineList)
    serviceRegistry = registry.MakeEtcdRegistry(etcdClient, machineList)
} else {
    taskRegistry = registry.MakeMemoryRegistry()
    controllerRegistry = registry.MakeMemoryRegistry()
    serviceRegistry = registry.MakeMemoryRegistry()
}

registry 是对具体资源对象的后端存储的抽象，这里定义了三个 registry，并根据命令行参数判断是使用 etcd 还是内存作为存储后端。

// 代码路径：pkg/registry/interfaces.go
// TaskRegistry is an interface implemented by things that know how to store Task objects
type TaskRegistry interface {
// ListTasks obtains a list of tasks that match query.
// Query may be nil in which case all tasks are returned.
ListTasks(query *map[string]string) ([]api.Task, error)
// Get a specific task
GetTask(taskId string) (*api.Task, error)
// Create a task based on a specification, schedule it onto a specific machine.
CreateTask(machine string, task api.Task) error
// Update an existing task
UpdateTask(task api.Task) error
// Delete an existing task
DeleteTask(taskId string) error
}

其中taskRegistry是对 task 的存储抽象，task 可以当作 pod 的前身看待，实现了对 task 的 list，get，create, update, delete 的操作。

// 代码路径：pkg/registry/interfaces.go
// ControllerRegistry is an interface for things that know how to store Controllers
type ControllerRegistry interface {
ListControllers() ([]api.ReplicationController, error)
GetController(controllerId string) (*api.ReplicationController, error)
CreateController(controller api.ReplicationController) error
UpdateController(controller api.ReplicationController) error
DeleteController(controllerId string) error
}

而ControllerRegistry是对 RC(Replication Controller) 的存储抽象，而我们现在使用的较多的是 RS(RepicateSet)， RS 正是 RC 的升级，同样是实现了对 RC 的 list，get，create，update，delete 操作。

// 代码路径：pkg/registry/service_registry.go
type ServiceRegistry interface {
ListServices() (ServiceList, error)
CreateService(svc Service) error
GetService(name string) (*Service, error)
DeleteService(name string) error
UpdateService(svc Service) error
UpdateEndpoints(e Endpoints) error
}

ServiceRegistry是对 service 的存储抽象

containerInfo := &kube_client.HTTPContainerInfo{
    Client: http.DefaultClient,
    Port:   10250,
}

storage := map[string]apiserver.RESTStorage{
    "tasks":                  registry.MakeTaskRegistryStorage(taskRegistry, containerInfo, registry.MakeFirstFitScheduler(machineList, taskRegistry)),
    "replicationControllers": registry.MakeControllerRegistryStorage(controllerRegistry),
    "services":               registry.MakeServiceRegistryStorage(serviceRegistry),
}

storge 是对所有资源的 registry 的统一抽象，被定义为 REST 风格的资源操作接口。

// 代码路径: pkg/apiserver/api_server.go
// RESTStorage is a generic interface for RESTful storage services
type RESTStorage interface {
List(*url.URL) (interface{}, error)
Get(id string) (interface{}, error)
Delete(id string) error
Extract(body string) (interface{}, error)
Create(interface{}) error
Update(interface{}) error
}

实例化所有资源的 storage 后放在 map 中维护，用于后面 handler 的处理。

s := &http.Server{
    Addr:           fmt.Sprintf("%s:%d", *address, *port),
    Handler:        apiserver.New(storage, *apiPrefix),  // 使用 REST storage 创建请求的 handler
    ReadTimeout:    10 * time.Second,
    WriteTimeout:   10 * time.Second,
    MaxHeaderBytes: 1 << 20,
}
log.Fatal(s.ListenAndServe())

使用前面的 REST Storage map 和 api prefix 创建 handler，启动 HTTP 服务器等待接收请求。接下来转到 handler 分析源码

// 代码路径：pkg/apiserver/api_server.go
// New creates a new ApiServer object.
// 'storage' contains a map of handlers.
// 'prefix' is the hosting path prefix.
func New(storage map[string]RESTStorage, prefix string) *ApiServer {
return &ApiServer{
storage: storage,
prefix:  prefix,
}
}

// HTTP Handler interface
func (server *ApiServer) ServeHTTP(w http.ResponseWriter, req *http.Request) {
log.Printf("%s %s", req.Method, req.RequestURI)
url, err := url.ParseRequestURI(req.RequestURI)
if err != nil {
server.error(err, w)
return
}
if url.Path == "/index.html" || url.Path == "/" || url.Path == "" {
server.handleIndex(w)
return
}
if !strings.HasPrefix(url.Path, server.prefix) {
server.notFound(req, w)
return
}
requestParts := strings.Split(url.Path[len(server.prefix):], "/")[1:]
if len(requestParts) < 1 {
server.notFound(req, w)
return
}
storage := server.storage[requestParts[0]]
if storage == nil {
server.notFound(req, w)
return
} else {
server.handleREST(requestParts, url, req, w, storage)
}
}

Golang HTTP 的标准库是通过实现 Handler 接口的 ServeHTTP 函数来实现处理请求，通过代码可以看出先对请求的 URL 进行解析获取具体的资源对象，再通过 REST storage map 拿到对应资源对象的 REST storage，最后调用 server.handleREST来处理具体的请求。

// 代码路径：pkg/apiserver/api_server.go
func (server *ApiServer) handleREST(parts []string, url *url.URL, req *http.Request, w http.ResponseWriter, storage RESTStorage) {
switch req.Method {
case "GET":
switch len(parts) {
case 1:
controllers, err := storage.List(url)
if err != nil {
server.error(err, w)
return
}
server.write(200, controllers, w)
case 2:
task, err := storage.Get(parts[1])
if err != nil {
server.error(err, w)
return
}
if task == nil {
server.notFound(req, w)
return
}
server.write(200, task, w)
default:
server.notFound(req, w)
}
return
case "POST":
if len(parts) != 1 {
server.notFound(req, w)
return
}
body, err := server.readBody(req)
if err != nil {
server.error(err, w)
return
}
obj, err := storage.Extract(body)
if err != nil {
server.error(err, w)
return
}
storage.Create(obj)
server.write(200, obj, w)
return
case "DELETE":
if len(parts) != 2 {
server.notFound(req, w)
return
}
err := storage.Delete(parts[1])
if err != nil {
server.error(err, w)
return
}
server.write(200, Status{success: true}, w)
return
case "PUT":
if len(parts) != 2 {
server.notFound(req, w)
return
}
body, err := server.readBody(req)
if err != nil {
server.error(err, w)
}
obj, err := storage.Extract(body)
if err != nil {
server.error(err, w)
return
}
err = storage.Update(obj)
if err != nil {
server.error(err, w)
return
}
server.write(200, obj, w)
return
default:
server.notFound(req, w)
}
}

可以很清晰的看出，这段逻辑是根据请求方法和请求参数对实际的资源对象进行特定的 REST 的操作。

回到 main 函数，在启动 HTTP server 之前还启动了一个 goroutine 做定时任务

1 2	endpoints := registry.MakeEndpointController(serviceRegistry, taskRegistry) go util.Forever(func() { endpoints.SyncServiceEndpoints() }, time.Second*10)

其中 util.Forever就是周期性任务的封装

// 代码路径: pkg/util/util.go
// Loops forever running f every d.  Catches any panics, and keeps going.
func Forever(f func(), period time.Duration) {
for {
func() {
defer HandleCrash()
f()
}()
time.Sleep(period)
}
}

任务实体endpoints.SyncServiceEndpoints逻辑如下

// 代码路径: pkg/registry/endpoint.go
func (e *EndpointController) SyncServiceEndpoints() error {
services, err := e.serviceRegistry.ListServices()
if err != nil {
return err
}
var resultErr error
for _, service := range services.Items {
tasks, err := e.taskRegistry.ListTasks(&service.Labels)
if err != nil {
log.Printf("Error syncing service: %#v, skipping.", service)
resultErr = err
continue
}
endpoints := make([]string, len(tasks))
for ix, task := range tasks {
// TODO: Use port names in the service object, don't just use port #0
endpoints[ix] = fmt.Sprintf("%s:%d", task.CurrentState.Host, task.DesiredState.Manifest.Containers[0].Ports[0].HostPort)
}
err = e.serviceRegistry.UpdateEndpoints(Endpoints{
Name:      service.ID,
Endpoints: endpoints,
})
if err != nil {
log.Printf("Error updating endpoints: %#v", err)
continue
}
}
return resultErr
}

可以看到主要逻辑就是定时获取所有 service 列表，再遍历 service 列表查询 service 下所有 task，最后根据 task 的 endpoint 来更新 service 的 endpoints。这一段逻辑其实就是为 kubeproxy 做负载均衡用的，让 kubeproxy 知道需要代理的 endpoint 有哪些。这一块逻辑在现在的 k8s 架构中已经从 api-server 中移除了。

笔者只分析了 api-server 主体的逻辑，后续会分析具体 registry 的逻辑。

Linux驱动之网卡驱动剖析

2021-10-11T14:52:05.000Z

网络设备不同于字符设备和块设备，并不对应于/dev目录下的文件，应用程序通过 socket 完成与网络设备的交互，在网络设备上并不体现”一切皆文件”的设计思想。

Linux 网络设备驱动架构

驱动架构自上而下分为4层：

协议接口层
设备接口层
设备驱动功能层
网络设备与媒介层

协议接口层

协议接口层主要功能是给上层协议提供接收和发送的接口。当内核协议栈需要发送数据时，会通过调用 dev_queue_xmit 函数来发送数据。同样内核协议栈接收数据也是通过协议接口层的 netif_rx 函数来进行的。传递的数据被描述为套接字缓冲区，用struct sk_buff结构描述，该结构体定义位于include/linux/skbuff.h中，用于在Linux网络子系统中的各层之间传输数据，该结构在整个网络收发过程中贯穿始终。

sk buffer 结构可以分为两部分，一部分是存储真正的数据包，在图中为 Packetdata，另一部分是一组指针组成。

head 指向内核缓冲区(Packetdata)的头部(headroom)
data 指向的是实际数据包的头部
tail 指向的是实际数据包的尾部
end 指向内核缓冲区的尾部

设备接口层

网络设备接口层用于抽象各种不同的网络设备，用 struct net_device来表示网络设备，该结构地位等同于字符设备的抽象描述struct cdev。

设备驱动功能层

类似于字符设备，struct net_device结构体也提供了一个操作函数集struct net_device_ops来描述对网卡的各种操作。

源码分析

笔者基于的是 S5PV210 的 DM9000 驱动，会大体上对 DM9000 的驱动源码进行分析, 分析源码位于DM9000 源码

platform 框架分析

DM9000 的驱动是基于 platform 架构实现，首先从 platform 框架入手。

static struct platform_driver dm9000_driver = {
    .driver    = {
        .name    = "dm9000",
        .owner     = THIS_MODULE,
        .pm     = &dm9000_drv_pm_ops,
    },
    .probe   = dm9000_probe,
    .remove  = __devexit_p(dm9000_drv_remove),
};

static int __init dm9000_init(void)
{
    /* disable buzzer */
    s3c_gpio_setpull(S5PV210_GPD0(2), S3C_GPIO_PULL_UP);
    s3c_gpio_cfgpin(S5PV210_GPD0(2), S3C_GPIO_SFN(1));
    gpio_set_value(S5PV210_GPD0(2), 0);

    dm9000_power_int();
    printk(KERN_INFO "%s Ethernet Driver, V%s\n", CARDNAME, DRV_VERSION);

    return platform_driver_register(&dm9000_driver);
}

该函数调用了 platform_driver_register 函数注册了一个平台总线驱动，对应的平台设备的注册定义位于 xxx_machine_init中，在笔者基于的s5pv210 kernel 上位于arch/arm/mach-s5pv210/mach-x210.c中的smdkc110_machine_init中，具体的分析过程省略，笔者直接列出对应的平台总线设备。

/* DM9000 registrations */
#ifdef CONFIG_DM9000
static struct resource s5p_dm9000_resources[] = {
    [0] = {
        .start = S5P_PA_DM9000,
        .end   = S5P_PA_DM9000 + 3,
        .flags = IORESOURCE_MEM,    // 内存资源 (DM900 地址端口)
    },
    [1] = {
        .start = S5P_PA_DM9000 + 4,
        .end   = S5P_PA_DM9000 + 7,
        .flags = IORESOURCE_MEM,      // 内存资源  (DM900 数据端口)
    },
    [2] = {
        .start = IRQ_EINT10,
        .end   = IRQ_EINT10,
        .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL, // 中断资源 （高电平触发）
    }
};

static struct dm9000_plat_data s5p_dm9000_platdata = {
    .flags = DM9000_PLATF_16BITONLY | DM9000_PLATF_NO_EEPROM,
    .dev_addr = {0x00,0x09,0xc0,0xff,0xec,0x48},
};

struct platform_device s5p_device_dm9000 = {
    .name      = "dm9000",
    .id        =  0,
    .num_resources    = ARRAY_SIZE(s5p_dm9000_resources),
    .resource   = s5p_dm9000_resources,
    .dev        = {
        .platform_data = &s5p_dm9000_platdata,
    }
};

根据平台总线的原理，驱动和设备匹配上后，会调用驱动的 probe 函数 dm9000_probe，分段进行分析

struct dm9000_plat_data *pdata = pdev->dev.platform_data;
struct board_info *db;    /* Point a board information structure */
struct net_device *ndev;   /* struct net_device 为网络设备的抽象 */
const unsigned char *mac_src;
int ret = 0;
int iosize;
int i;
u32 id_val;

/* Init network device */
ndev = alloc_etherdev(sizeof(struct board_info)); /* 同时为 ndev 和 db 申请内存, db 内存位于 ndev 后面 */
if (!ndev) {
    dev_err(&pdev->dev, "could not allocate device.\n");
    return -ENOMEM;
}

SET_NETDEV_DEV(ndev, &pdev->dev);

dev_dbg(&pdev->dev, "dm9000_probe()\n");dm9000_opendm9000_open

/* setup board info structure */
db = netdev_priv(ndev);

db->dev = &pdev->dev;
db->ndev = ndev;

spin_lock_init(&db->lock);
mutex_init(&db->addr_lock);

INIT_DELAYED_WORK(&db->phy_poll, dm9000_poll_work);

该部分为 struct net_device 和 struct board_info 结构体申请内存，struct board_info定义在 DM9000 的驱动文件中，表示设备的私有数据，随后对各个指针做了挂接，并初始化了一部分 struct board_info 中的成员。

   db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0); /* dm9000 地址端口 */
   db->data_res = platform_get_resource(pdev, IORESOURCE_MEM, 1); /* dm9000 数据端口 */
   db->irq_res  = platform_get_resource(pdev, IORESOURCE_IRQ, 0); /* dm9000 irq 号 */

   if (db->addr_res == NULL || db->data_res == NULL ||
       db->irq_res == NULL) {
       dev_err(db->dev, "insufficient resources\n");
       ret = -ENOENT;
       goto out;
   }

/*
 * 第二个参数为 1 表示获取的是第二个中断资源。
 * 由于只定义了一个中断, 所以返回 -ENXIO
 */
   db->irq_wake = platform_get_irq(pdev, 1);
   if (db->irq_wake >= 0) {
   /* 这一段代码并不会执行, 省略 */
       // ...
   }

   iosize = resource_size(db->addr_res); // res->end - res->start + 1 = 4
   /* 申请地址端口内存 */
   db->addr_req = request_mem_region(db->addr_res->start, iosize,
                     pdev->name);

   if (db->addr_req == NULL) {
       dev_err(db->dev, "cannot claim address reg area\n");
       ret = -EIO;
       goto out;
   }

/* 映射地址端口虚拟地址 */
   db->io_addr = ioremap(db->addr_res->start, iosize);

   if (db->io_addr == NULL) {
       dev_err(db->dev, "failed to ioremap address reg\n");
       ret = -EINVAL;
       goto out;
   }


   iosize = resource_size(db->data_res);
   /* 申请数据端口内存 */
   db->data_req = request_mem_region(db->data_res->start, iosize,
                     pdev->name);

   if (db->data_req == NULL) {
       dev_err(db->dev, "cannot claim data reg area\n");
       ret = -EIO;
       goto out;
   }

  /* 映射数据端口虚拟地址 */
   db->io_data = ioremap(db->data_res->start, iosize);

   if (db->io_data == NULL) {
       dev_err(db->dev, "failed to ioremap data reg\n");
       ret = -EINVAL;
       goto out;
   }

   /* fill in parameters for net-dev structure */
   ndev->base_addr = (unsigned long)db->io_addr;
   ndev->irq       = db->irq_res->start;

以上代码从platform_device中获取 DM9000 资源: 地址端口、数据端口地址和中断号, 并为端口地址 ioremap。

    /* ensure at least we have a default set of IO routines */
    dm9000_set_io(db, iosize); /* 在下面 if 判断中还会设置一次, 所以这里设置无效 */

    /* check to see if anything is being over-ridden */
    if (pdata != NULL) {
        /* check to see if the driver wants to over-ride the
         * default IO width */

        if (pdata->flags & DM9000_PLATF_8BITONLY)
            dm9000_set_io(db, 1);

        if (pdata->flags & DM9000_PLATF_16BITONLY)  /* 只有这个 if 成立 */
            dm9000_set_io(db, 2);  /* 设置 board_info 的读写函数 */

        if (pdata->flags & DM9000_PLATF_32BITONLY)
            dm9000_set_io(db, 4);

        /* check to see if there are any IO routine
         * over-rides */

        if (pdata->inblk != NULL)
            db->inblk = pdata->inblk;

        if (pdata->outblk != NULL)
            db->outblk = pdata->outblk;

        if (pdata->dumpblk != NULL)
            db->dumpblk = pdata->dumpblk;

        db->flags = pdata->flags;
    }

#ifdef CONFIG_DM9000_FORCE_SIMPLE_PHY_POLL
    db->flags |= DM9000_PLATF_SIMPLE_PHY;
#endif

    dm9000_reset(db);    /* 重启 dm9000 */

根据平台设备的平台数据，DM9000 配置在了 16bit 的模式下，所以这一部分设置只有dm9000_set_io(db, 2);是成功的。 dm9000_set_io 函数用于设置 DM9000 的读写函数。

static void dm9000_set_io(struct board_info *db, int byte_width)
{
/* use the size of the data resource to work out what IO
 * routines we want to use
 */

switch (byte_width) {
case 1:
db->dumpblk = dm9000_dumpblk_8bit;
db->outblk  = dm9000_outblk_8bit;
db->inblk   = dm9000_inblk_8bit;
break;


case 3:
dev_dbg(db->dev, ": 3 byte IO, falling back to 16bit\n");
case 2:
db->dumpblk = dm9000_dumpblk_16bit;
db->outblk  = dm9000_outblk_16bit;
db->inblk   = dm9000_inblk_16bit;
break;

case 4:
default:
db->dumpblk = dm9000_dumpblk_32bit;
db->outblk  = dm9000_outblk_32bit;
db->inblk   = dm9000_inblk_32bit;
break;
}
}

设置完读写函数后，软件重启 DM9000。

static void dm9000_reset(board_info_t * db)
{
dev_dbg(db->dev, "resetting device\n");

/* RESET device */
writeb(DM9000_NCR, db->io_addr); //  DM9000_NCR: 0x00
udelay(200);
writeb(NCR_RST, db->io_data);    // NCR_RST: 1 << 0
udelay(200);
}

DM9000 通过端口来操作寄存器, 先将寄存器的偏移值或命令码写入地址端口, 再将值写入数据端口。重启 DM900 只需往地址为 0 的端口写入 1。

重启完 DM9000 后，开始读取 DM9000 的寄存器

/* try multiple times, DM9000 sometimes gets the read wrong */
for (i = 0; i < 8; i++) {
    id_val  = ior(db, DM9000_VIDL);             /* DM9000_VIDL：0x28, 读取 vendor id */
    id_val |= (u32)ior(db, DM9000_VIDH) << 8;   /* DM9000_VIDH: 0x29 */
    id_val |= (u32)ior(db, DM9000_PIDL) << 16;  /* DM9000_PIDL: 0x2A, 读取 product id */
    id_val |= (u32)ior(db, DM9000_PIDH) << 24;  /* DM9000_PIDH: 0x2B */

    if (id_val == DM9000_ID)   /* 验证是否是 DM900 */
        break;
    dev_err(db->dev, "read wrong id 0x%08x\n", id_val);
}

if (id_val != DM9000_ID) {
    dev_err(db->dev, "wrong id: 0x%08x\n", id_val);
    ret = -ENODEV;
    goto out;
}

/* Identify what type of DM9000 we are working on */

/* I/O mode */
db->io_mode = ior(db, DM9000_ISR) >> 6;    /* ISR bit7:6 keeps I/O mode */ // 读取 I/O mode
id_val = ior(db, DM9000_CHIPR);  /* DM9000_CHIPR: 0x2C, 读取 chip revision */
dev_dbg(db->dev, "dm9000 revision 0x%02x  , io_mode %02x \n", id_val, db->io_mode);

switch (id_val) {
case CHIPR_DM9000A:
    db->type = TYPE_DM9000A;
    break;
case 0x1a:
    db->type = TYPE_DM9000C;
    break;
default:
    dev_dbg(db->dev, "ID %02x => defaulting to DM9000E\n", id_val);
    db->type = TYPE_DM9000E;
}

读取 vendor id 和 product id 验证是否是 DM9000。再读取 I/O mode 和 chip revision, 并根据不同 revision 对db->type进行赋值。

/* driver system function */
ether_setup(ndev);

ndev->netdev_ops    = &dm9000_netdev_ops;     // net device 的 ops
ndev->watchdog_timeo    = msecs_to_jiffies(watchdog);
ndev->ethtool_ops    = &dm9000_ethtool_ops;   // ethtool 的 ops, 用于支持应用层的 ethtool 命令

db->msg_enable       = NETIF_MSG_LINK;
db->mii.phy_id_mask  = 0x1f;
db->mii.reg_num_mask = 0x1f;
db->mii.force_media  = 0;
db->mii.full_duplex  = 0;
db->mii.dev         = ndev;
db->mii.mdio_read    = dm9000_phy_read;
db->mii.mdio_write   = dm9000_phy_write;

mac_src = "eeprom";

/* try reading the node address from the attached EEPROM */
/* platdata 设置了 DM9000_PLATF_NO_EEPROM flag, 所以这个读取无效 */
for (i = 0; i < 6; i += 2)
    dm9000_read_eeprom(db, i / 2, ndev->dev_addr+i);

if (!is_valid_ether_addr(ndev->dev_addr) && pdata != NULL) {
    mac_src = "platform data";
    //memcpy(ndev->dev_addr, pdata->dev_addr, 6);
    /* mac from bootloader */
    memcpy(ndev->dev_addr, mac, 6);  /* 这是真正的设置 mac 地址, 其他设置均无效 */
}

if (!is_valid_ether_addr(ndev->dev_addr)) {
    /* try reading from mac */

    mac_src = "chip";
    for (i = 0; i < 6; i++)
        ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
}

if (!is_valid_ether_addr(ndev->dev_addr))
    dev_warn(db->dev, "%s: Invalid ethernet MAC address. Please "
         "set using ifconfig\n", ndev->name);

platform_set_drvdata(pdev, ndev);
ret = register_netdev(ndev);   // 注册网络设备

if (ret == 0)
    printk(KERN_INFO "%s: dm9000%c at %p,%p IRQ %d MAC: %pM (%s)\n",
           ndev->name, dm9000_type_to_char(db->type),
           db->io_addr, db->io_data, ndev->irq,
           ndev->dev_addr, mac_src);
return 0;

调用ether_setup函数对ndev成员进行初始化。

void ether_setup(struct net_device *dev)
{
    dev->header_ops   = ð_header_ops; /* 硬件头部操作函数集，主要完成创建硬件头和从 sk_buf 分析硬件头等操作 */
    dev->type         = ARPHRD_ETHER;    // 设置以太网协议
    dev->hard_header_len     = ETH_HLEN; // 以太网头部大小   14B
    dev->mtu          = ETH_DATA_LEN;    // 设置以太网 MTU  1500B
    dev->addr_len     = ETH_ALEN;        // mac 地址长度    6B
    dev->tx_queue_len = 1000;    /* Ethernet wants good queues */
    dev->flags        = IFF_BROADCAST|IFF_MULTICAST;

    memset(dev->broadcast, 0xFF, ETH_ALEN);
}

初始化完ndev后，设置了netdev_ops 和 mac 地址，最后调用register_netdev函数注册了网络设备。至此，probe 函数分析完毕，紧接着把关注点放在netdev_ops上。

static const struct net_device_ops dm9000_netdev_ops = {
.ndo_open= dm9000_open,              /* ifconfig eth0 up */
.ndo_stop= dm9000_stop,              /* ifconfig eth0 down */
.ndo_start_xmit= dm9000_start_xmit,    /* 数据包发送时由网络协议栈调用 */
.ndo_tx_timeout= dm9000_timeout,       /* 数据包发送超时后会被调用　*/
.ndo_set_multicast_list= dm9000_hash_table,
.ndo_do_ioctl= dm9000_ioctl,
.ndo_change_mtu= eth_change_mtu,
.ndo_validate_addr= eth_validate_addr,
.ndo_set_mac_address= eth_mac_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller= dm9000_poll_controller,
#endif
};

dm9000 open 过程分析

当用户执行命令ifconfig eth0 up后会调用网卡驱动的 open 函数

/*
 *  Open the interface.
 *  The interface is opened whenever "ifconfig" actives it.
 */
static int dm9000_open(struct net_device *dev)
{
board_info_t *db = netdev_priv(dev);
unsigned long irqflags = db->irq_res->flags & IRQF_TRIGGER_MASK;

if (netif_msg_ifup(db))
dev_dbg(db->dev, "enabling %s\n", dev->name);

/* If there is no IRQ type specified, default to something that
 * may work, and tell the user that this is a problem */

if (irqflags == IRQF_TRIGGER_NONE)
dev_warn(db->dev, "WARNING: no IRQ resource flags set.\n");

irqflags |= IRQF_SHARED;

/* 申请收发中断 */
if (request_irq(dev->irq, dm9000_interrupt, irqflags, dev->name, dev))
return -EAGAIN;

/* Initialize DM9000 board */
//dm9000_reset(db);
dm9000_init_dm9000(dev);   /* 初始化 DM9000 */

/* Init driver variable */
db->dbug_cnt = 0;

mii_check_media(&db->mii, netif_msg_link(db), 1);
netif_start_queue(dev);   /* 激活设备发送队列，允许上层调用 xxx_xmit 函数 */

dm9000_schedule_poll(db);

return 0;
}

open 函数主要做了申请收发中断、初始化 DM9000、激活设备发送队列。其中 DM900 的初始化全是对硬件寄存器的操作，在此省略。

DM9000 发送过程分析

应用程序调用send函数去发送数据，内核协议栈会将数据构造成struct sk_buff后放入等待队列，调用start_xmit通知网卡发送数据。

static int dm9000_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
board_info_t *db = netdev_priv(dev);

dm9000_dbg(db, 3, "%s:\n", __func__);

if ((db->tx_pkt_cnt > 0) && !netif_carrier_ok(dev))
return NETDEV_TX_BUSY;

spin_lock_irqsave(&db->lock, flags);

netif_stop_queue(dev);  /* 关闭发送队列，通知协议接口层停止向下递交数据包 */

db->tx_pkt_cnt++;
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;

/* Set TX length to DM9000 */       // 设置数据包总长度
iow(db, DM9000_TXPLL, skb->len);    // DM9000_TXPLL: 0xFC
iow(db, DM9000_TXPLH, skb->len >> 8); // DM9000_TXPLH: 0xFD

/* Move data to DM9000 TX RAM */   /* 将数据包放入 TX SRAM 中 */
writeb(DM9000_MWCMD, db->io_addr);   // DM9000_MWCMD: 0xF8
(db->outblk)(db->io_data, skb->data, skb->len);

/* Issue TX polling command */  /* 开始将 TX SRAM 中的数据发送出去, 发送完毕会通过中断告知 */
iow(db, DM9000_TCR, TCR_TXREQ);/* Cleared after TX complete */ // DM9000_TCR: 0x02, TCR_TXREQ: 1 << 0
dev->trans_start = jiffies;

spin_unlock_irqrestore(&db->lock, flags);

/* free this SKB */
dev_kfree_skb(skb);

return NETDEV_TX_OK;
}

由以上代码可知，先关闭发送队列，通知协议接口层停止向下递交数据包, 然后设置数据包的总长度后将数据包拷贝进 DM9000 的 TX SRAM 中，再然后置位 TCR 寄存器后网卡开始发送数据，该标志位会在发送完毕后硬件自动清 0, 最后由中断通知 CPU 数据发送完毕

在 open 函数中申请过 DM9000 的硬件中断，该中断在发送和接收完毕都会触发，在这先只关注中断处理函数的发送完毕过程

static irqreturn_t dm9000_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
board_info_t *db = netdev_priv(dev);
int int_status;
unsigned long flags;
u8 reg_save;

dm9000_dbg(db, 3, "entering %s\n", __func__);

/* A real interrupt coming */

/* holders of db->lock must always block IRQs */
spin_lock_irqsave(&db->lock, flags);

/* Save previous register address */
reg_save = readb(db->io_addr);

/* Disable all interrupts */
iow(db, DM9000_IMR, IMR_PAR);   // 先 disable 掉所有中断

/* Got DM9000 interrupt status */
int_status = ior(db, DM9000_ISR);/* Got ISR */  /* 获取中断状态, 是接收中断还是发送中断 */
iow(db, DM9000_ISR, int_status);/* Clear ISR status */  /* 清中断 */

if (netif_msg_intr(db))
dev_dbg(db->dev, "interrupt status %02x\n", int_status);

/* Received the coming packet */
if (int_status & ISR_PRS)   /* ISR_PRS: 1 << 0, 接收中断 */
dm9000_rx(dev);

/* Got DM9000 interrupt status */
int_status |= ior(db, DM9000_ISR);/* Got ISR */

/* Trnasmit Interrupt check */
if (int_status & ISR_PTS)   /* ISR_PTS: 1 << 1, 发送中断 */
{
iow(db, DM9000_ISR, ISR_PTS);/* Clear ISR status */
dm9000_tx_done(dev, db);
}

if (db->type != TYPE_DM9000E) {
if (int_status & ISR_LNKCHNG) {
/* fire a link-change request */
schedule_delayed_work(&db->phy_poll, 1);
}
}

/* Re-enable interrupt mask */
iow(db, DM9000_IMR, db->imr_all);

/* Restore previous register address */
writeb(reg_save, db->io_addr);

spin_unlock_irqrestore(&db->lock, flags);

return IRQ_HANDLED;
}

先禁用所有中断，然后通过读取 ISR 寄存器获取中断状态

由 bit 0 和 1 可判断是接收中断还是发送中断，如果是发送中断，则清中断后调用dm9000_tx_done函数

static void dm9000_tx_done(struct net_device *dev, board_info_t *db)
{
int tx_status = ior(db, DM9000_TCR);/* Got TX status */

if (tx_status & TCR_TXREQ) {
dev->stats.tx_fifo_errors++;
} else {
if (db->tx_pkt_cnt && !db->wait_reset) {
/* One packet sent complete */
db->tx_pkt_cnt = 0;
dev->trans_start = 0;
netif_wake_queue(dev);  /* 唤醒发送队列，协议接口层可以继续向下递交数据了 */
}
}
}

再次读取寄存器状态，如果发送中断未置位，则唤醒发送队列，表示协议接口层可以继续向下递交数据了。由于在dm9000_start_xmit函数中将发送队列关闭了并且调用dm9000_tx_done前清了中断，此时如果中断仍置位，表示出错了，所以dev->stats.tx_fifo_errors++;

以 UDP 为例，下图说明 DM9000 发送数据包的流程

DM9000 接收过程分析

由发送过程分析可知，接收也是由中断通知的。而且与发送过程共用同一个中断处理函数，当中断是接收中断时会调用dm9000_rx函数来处理接收过程。

RX SRAM 中一个完整数据包包含 4 字节的头部，其中第一个字节固定为 0x01, 第二个字节为数据包状态，最后两个字节表示有效数据的长度。驱动代码中用这样一个结构体来表示头部，头部之后的数据才为真正有效数据

struct dm9000_rxhdr {
u8RxPktReady;    // 固定为 0x01
u8RxStatus;
__le16RxLen;
} __attribute__((__packed__));

dm9000_rx函数比较长，关键部分都在代码中注释说明

static void dm9000_rx(struct net_device *dev)
{
board_info_t *db = netdev_priv(dev);
struct dm9000_rxhdr rxhdr;   /* RX SRAM 存储的数据的四字节头部, 去除头部后才是数据包 */
struct sk_buff *skb;
u8 rxbyte, *rdptr;
bool GoodPacket;
int RxLen;
int save_mrr, calc_mrr, check_mrr;

/* Check packet ready or not */
do {
ior(db, DM9000_MRCMDX);/* Dummy read */
save_mrr = (ior(db, 0xf5) << 8) | ior(db, 0xf4);
/* Get most updated data */
rxbyte = ior(db, DM9000_MRCMDX); /* 读取 RX SRAM 的数据, 地址不会自增 */

if(rxbyte != DM9000_PKT_RDY)  /* DM9000_PKT_RDY: 0x01, RX sram存储的数据的四字节头部第一字节固定为 0x01 */
{
/* Status check: this byte must be 0 or 1 */
if (rxbyte > DM9000_PKT_RDY) {
dev_warn(db->dev, "status check fail: %d\n", rxbyte);
iow(db, DM9000_RCR, 0x00);/* Stop Device */
iow(db, DM9000_IMR, IMR_PAR);/* Stop INT request */

db->wait_reset = 1;
dev->trans_start = 1;
}

return;
}

/* A packet ready now  & Get status/length */
GoodPacket = true;
writeb(DM9000_MRCMD, db->io_addr);  /* 读取 RX SRAM 的数据, 并且地址自增 */
(db->inblk)(db->io_data, &rxhdr, sizeof(rxhdr));

RxLen = le16_to_cpu(rxhdr.RxLen);  // 数据包的总长度

calc_mrr = save_mrr + 4 + RxLen;
if(0x00 == db->io_mode)  //16 bit only
{
if(RxLen & 0x01) calc_mrr++;
}
if(calc_mrr > 0x3fff) calc_mrr -= 0x3400;

if (netif_msg_rx_status(db))
dev_dbg(db->dev, "RX: status %02x, length %04x\n",
rxhdr.RxStatus, RxLen);

/* Packet Status check */
/* 64 < 以太网帧长度 <= 1536 */
if (RxLen < 0x40) {
GoodPacket = false;
if (netif_msg_rx_err(db))
dev_dbg(db->dev, "RX: Bad Packet (runt)\n");
}

if (RxLen > DM9000_PKT_MAX) {
dev_dbg(db->dev, "RST: RX Len:%x\n", RxLen);
}

        // 校验头部的状态值，判断是否是一个正常的数据包
/* rxhdr.RxStatus is identical to RSR register. */
if (rxhdr.RxStatus & (RSR_FOE | RSR_CE | RSR_AE |
      RSR_PLE | RSR_RWTO |
      RSR_LCS | RSR_RF)) {
if (rxhdr.RxStatus & RSR_FOE) {
if (netif_msg_rx_err(db))
dev_dbg(db->dev, "fifo error\n");
dev->stats.rx_fifo_errors++;
}
if (rxhdr.RxStatus & RSR_CE) {
if (netif_msg_rx_err(db))
dev_dbg(db->dev, "crc error\n");
dev->stats.rx_crc_errors++;
GoodPacket = false;
}
if (rxhdr.RxStatus & RSR_RF) {
if (netif_msg_rx_err(db))
dev_dbg(db->dev, "length error\n");
dev->stats.rx_length_errors++;
GoodPacket = false;
}
}

/* Move data from DM9000 */
if (GoodPacket &&
    ((skb = dev_alloc_skb(RxLen + 4)) != NULL)) {   // 如果是正常数据包，就申请 sk buffer
skb_reserve(skb, 2);
rdptr = (u8 *) skb_put(skb, RxLen - 4);

/* Read received packet from RX SRAM */

(db->inblk)(db->io_data, rdptr, RxLen);  // 将 RX SRAM 中的有效数据拷贝到 sk buffer 中
dev->stats.rx_bytes += RxLen;

/* Pass to upper layer */
skb->protocol = eth_type_trans(skb, dev);

netif_rx(skb);           /* 将 skb uffer 向上递交给协议接口层 */
dev->stats.rx_packets++;

check_mrr = (ior(db, 0xf5) << 8) | ior(db, 0xf4);
if(calc_mrr != check_mrr)
{

if (netif_msg_rx_err(db))
dev_dbg(db->dev, "rx point error %04x %04x %04x %04x\n",
save_mrr, RxLen, calc_mrr, check_mrr);

iow(db, 0xf5, (calc_mrr >> 8) & 0xff);
iow(db, 0xf4, calc_mrr & 0xff);
}

} else {
/* need to dump the packet's data */
iow(db, 0xf5, (calc_mrr >> 8) & 0xff);
iow(db, 0xf4, calc_mrr & 0xff);
}

} while (rxbyte & DM9000_PKT_RDY);
}

大体逻辑可以归为以下流程：

1.先读取 RX SRAM 中 4 字节头部到struct dm9000_rxhdr rxhdr中

2.判断第一字节是否为 0x01, 判断数据包总长度是否符合以太网规范，最后根据头部中的状态值是否是一个正常的封包

3.经过 2 判断是正常封包后，读取有效数据

4.创建分配 sk buffer，并将有效数据拷贝到 sk buffer 中

5.调用netif_rx, 将 sk buffer 向上递交给协议接口层

以 UDP 为例，下图说明 DM9000 接收数据包的流程

NAPI 方式接收介绍

通常情况下，网络驱动以中断方式接收数据，但是当数据量大的时候会频繁产生中断，CPU 要频繁去处理中断导致效率低下而不如纯轮询模式。在 kernel 2.5 之后引入了新的处理方式，叫 NAPI，综合了中断方式和轮询方式。NAPI 这个名字取得不知所云，据说由于当时未找到合适的名字，就叫 NAPI (New API)，目前已经公认为专有名词了。

NAPI 接收数据的流程：接收中断来临 -> 关闭接收中断 -> 轮询方式接收所有数据包直到为空 -> 开启接收中断 -> 接收中断来临 -> …

笔者在 DM9000 中加入了 NAPI 的支持 git commit。

主要修改如下：

1.在driver/net/Kconfig中加入配置

config DM9000_NAPI
    bool "DM9000 NAPI"
    depends on DM9000
    default n
    help
        Support DM9000 driver run NAPI mode

２.在struct board_info添加成员

1
2
3

#ifdef CONFIG_DM9000_NAPI
    struct napi_struct napi;
#endif

３.在 probe 函数中调用netif_napi_add注册 NAPI 要调度执行的轮询函数

#define DM9000_NAPI_WEIGHT 64

#ifdef CONFIG_DM9000_NAPI
    netif_napi_add(ndev, &db->napi, dm9000_napi_poll, DM9000_NAPI_WEIGHT);
#endif

dm9000_napi_poll函数如下

#ifdef CONFIG_DM9000_NAPI
static int dm9000_napi_poll(struct napi_struct *napi, int budget)
{
    board_info_t *db = container_of(napi, board_info_t, napi);
    unsigned long flags;
    u8 reg_save;

    spin_lock_irqsave(&db->lock, flags);

    reg_save = readb(db->io_addr);

    dm9000_rx(db->ndev, budget);    // 轮询处理收包

    napi_complete(napi);

    iow(db, DM9000_IMR, db->imr_all);

    writeb(reg_save, db->io_addr);

    spin_unlock_irqrestore(&db->lock, flags);

    return 0;
}
#endif

dm9000_rx轮询处理完收包后，需要调用napi_complete表示轮询完毕。

４.在 open 函数中调用napi_enable使能 NAPI 调度

1
2
3

#ifdef CONFIG_DM9000_NAPI
    napi_enable(&db->napi);
#endif

同样在 stop 函数中禁止 NAPI 调度

1
2
3

#ifdef CONFIG_DM9000_NAPI
    napi_disable(&db->napi);
#endif

公网环境搭建 k8s 集群

2021-08-09T15:29:03.000Z

笔者利用手头几台云服务器搭建 k8s 集群，由于这几台云服务属于不同的云服务厂商，无法搭建局域网环境的 k8s 集群，故笔者搭建的是公网环境的 k8s 集群，在此做个记录, 以下均在 ubuntu 20.04 环境下进行

创建虚拟网卡

由于主机内看到的只有内网 IP, 而且几台云服务器位于不同的内网, 直接搭建会将内网 IP 注册进集群导致搭建不成功。解决方案：使用虚拟网卡绑定公网 IP, 使用该公网 IP 来注册集群

1 2	# 所有主机都要创建虚拟网卡，并绑定对应的公网 ip sudo ifconfig eth0:1 139.198.108.103

该设置方式在重启服务器后失效，持久化需要将配置写入/etc/network/interfaces或/etc/netplan/50-cloud-init.yaml

更新 /etc/hosts

将集群所有节点的公网 ip 和 hostname 对应关系写入/etc/hosts中

1	sudo vi /etc/hosts

关闭 swap 分区

1
2
3

sudo swapoff -a
# 注释掉 fstab 中 swap 分区的挂载信息
sudo sed -ri 's/.*swap.*/#&/' /etc/fstab

配置 systemd 来管理 docker 的 cgroup

sudo mkdir /etc/docker
cat <
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker

允许 iptables 检查桥接流量

cat <
br_netfilter
EOF

cat <
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

开启相关端口

master 节点

协议	方向	端口范围	作用	使用者
TCP	入站	6443	Kubernetes API 服务器	所有组件
TCP	入站	2379-2380	etcd 服务器客户端 API	kube-apiserver、etcd
TCP	入站	10250	Kubelet API	kubelet 自身、控制平面组件
TCP	入站	10251	kube-scheduler	kube-scheduler 自身
TCP	入站	10252	kube-controller-manager	kube-controller-manager 自身

worker 节点

协议	方向	端口范围	作用	使用者
TCP	入站	10250	Kubelet API	kubelet 自身、控制平面组件
TCP	入站	30000-32767	NodePort 服务	所有组件

所有节点

协议	方向	端口范围	作用	使用者
UDP	入站	8472	vxlan Overlay 网络通信	Overlay 网络

安装 kubeadm、kubelet 和 kubectl

kubeadm：用来初始化集群的指令
kubelet：在集群中的每个节点上用来启动 Pod 和容器等
kubectl：用来与集群通信的命令行工具

sudo apt install -y apt-transport-https ca-certificates curl

curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add
echo "deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

修改 kubelet 启动参数

添加 kubelet 的启动参数--node-ip=公网IP，每个主机都要添加并指定对应的公网 ip, 添加了这一步才能使用公网 ip 来注册进集群

1	sudo vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

初始化 master 节点

sudo kubeadm init \
    --kubernetes-version=v1.22.0 \
    --apiserver-advertise-address=139.198.108.103 \
    --control-plane-endpoint=139.198.108.103 \
    --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers \
    --service-cidr=10.10.0.0/16 \
    --pod-network-cidr=10.122.0.0/16

报错及解决：

ERROR ImagePull: failed to pull image registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:v1.8.4: output: Error response from daemon: manifest for registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:v1.8.4 not found: manifest unknown: manifest unknown

解决：

1.从官方镜像拉取 coredns

1
docker pull coredns/coredns

2.打 tag，修改镜像名

1
docker tag coredns/coredns:latest registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:v1.8.4

3.删除多余镜像

 1
docker rmi coredns/coredns:latest

初始化成功后输出如下

根据输出提示执行以下命令

1
2
3

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

记录下该命令，用于之后将 worker 节点加入集群

1 2	kubeadm join 139.198.108.103:6443 --token hnop0o.t16okler9962rroq \ --discovery-token-ca-cert-hash sha256:64c85683ac63f820e64787ed47674c7d470574feebcfe0f2142f45699cfe8ec6

修改`kube-apiserver`参数

在 master 节点，kube-apiserver 添加--bind-address和修改--advertise-addres

1	sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

安装 flannel 网络

在 master 节点执行

1 2	# 下载 flannel 的 yaml 配置文件 wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

修改 yaml 配置文件，添加两处地方和修改一处地方

1	vi kube-flannel.yml

args:
 - --public-ip=$(PUBLIC_IP)
 - --iface=eth0

env:
 - name: PUBLIC_IP
   valueFrom:
     fieldRef:
       fieldPath: status.podIP

net-conf.json: |
  {
    "Network": "10.122.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
  }

修改完后，开始安装网络插件

1	kubectl apply -f kube-flannel.yml

执行如下命令，等待一会儿，直到所有的容器组处于 Running 状态

1	watch -n 1 kubectl get pod -n kube-system -o wide

worker 节点加入集群

使用初始化 master 节点成功后输出的命令来加入集群，或者在 master 节点重新打印 token 和加入命令

1	kubeadm token create --print-join-command

在 worker 节点执行命令加入集群

1	sudo kubeadm join 139.198.108.103:6443 --token wm2039.cf8qnsrgyip6qvsz --discovery-token-ca-cert-hash sha256:64c85683ac63f820e64787ed47674c7d470574feebcfe0f2142f45699cfe8ec6

等待所有需要加入的节点加入成功后，在 master 节点执行下面命令，并等待所有节点状态变为 Ready （笔者搭建的一主两从的集群，均使用的公网 ip)

1	kubectl get nodes

测试

master 节点执行下面命令来部署 nginx

1 2	kubectl create deploy my-nginx --image=nginx kubectl expose deploy my-nginx --port=80 --type=NodePort

查看 nginx 部署的 pod 信息，可以看到 Pod ip，以及部署在哪一个节点上

1	kubectl get pods -o wide

尝试 ping Pod 的 ip，如果无法 ping 通，执行

1	sudo iptables -P FORWARD ACCEPT

docker 从 1.13 版本开始，可能将 iptables FORWARD chain 的默认策略设置为了 DROP，该设置会导致 ping 其他 node 上的 Pod ip 失败

查看 nginx 对外暴露的端口

1	kubectl get all

可以看到对外暴露的端口是 30950, 如果分别通过集群内所有节点的公网 ip 访问这个端口，能请求到 nginx 主页，则证明部署成功

安装 Dashboard

下载 dashboard 的 yaml 描述文件

1	wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml

修改下载下来的 recommend.yaml

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  ports:
    - port: 443
      targetPort: 8443
      nodePort: 30001    # 指定对外暴露的 port
  type: NodePort         # 指定服务类型为 NodePort
  selector:
    k8s-app: kubernetes-dashboard

应用修改后的 yaml 文件，创建 dashboard 服务

1	kubectl apply -f recommended.yaml

现在可以通过 30001 端口访问 dashboard 的登录页面了

如果使用的是 chrome 浏览器并出现了以上页面，可以鼠标点击页面任意地方，然后键盘输入 thisisunsafe。正常访问会进入 Login 页面，提示需要授权

接下来创建 admin 用户来获取 token

1	vi dashboard-admin.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

创建 admin 用户并获取 token

1 2	kubectl apply -f dashboard-admin.yaml kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret \| grep admin-user \| awk '{print $1}')

在 Login 页面输入 token 后就可以成功访问 dashboard 页面了

Docker 入门之网络

2021-07-25T17:44:04.000Z

Docker 网络使用了 Linux 的 network namespace 机制，隔离了网络设备， ip 协议栈，路由表以及防火墙规则。

默认网络模式

每一个安装了 Docker 的 Linux 主机都会创建一个名为 docker0 的虚拟网桥，该虚拟网桥作为所有容器的默认网关。
在默认的网络模式下，虚拟网桥的工作方式和物理交换机类似，主机上的所有容器通过 docker0 连接在了一个二层网络中。

每启动一个容器，Docker 都会创建一个虚拟网卡，并根据 Docker 网桥所在的网段来分配给容器一个未使用的 ip 地址，称之为容器 ip。在宿主机和容器内分别创建了一个虚拟接口，它们彼此连通，这对接口称之为 veth pair。

默认情况下的网络模式称之为 bridge 模式，该模式为 docker 的默认模式。在启动 docker 时可以使用--net指定容器的网络模式

1	sudo docker run -it --net=bridge -p 9001:6379 redis:alpine

bridge 模式的网络转发如下图所示

四种网络模式

除了 brideg 模式，docker 还支持 container, host, none 模式

网络模式	配置	说明
bridge	`--net=bridge`	默认模式
container	`--net=container:name或id`	容器和另外一个容器共享 network namespace k8s 中的 pod 就是多个容器共享一个 network namespace
host	`--net=host`	容器和宿主机共享 network namespace
none	`--net=none`	不配置网络，用户可以稍后进入容器，自行配置

自定义网络

默认主机中创建了三个网络，可通过network ls命令查看

1	sudo docker network ls

用户可通过network create命令创建自定义网络

1
2

# 创建自定义网络 指定 bridge 模式，网段为 192.168.0.0/16， 网关为 192.168.0.0/16, 命名为 mynet
sudo docker network create --driver bridge --subnet 192.168.0.0/16 --gateway 192.168.0.1 mynet

启动容器可以指定连接到自定义网络

1
2
3

# 启动两个 redis 容器，分别命名为 redis1, redis2
sudo docker run -it -d --name redis1 -P --net mynet redis:alpine
sudo docker run -it -d --name redis2 -P --net mynet redis:alpine

通过network inspect命令可以查看一个网络的详情

1 2	# 查看 mynet 网络详细信息，参数为网络 id 或网络名，参数可通过 network ls 命令查到 sudo docker inspect e37aeda5814a

可以看到该网络下连接了两个容器

在以前可使用 --link 参数来使容器互联，但在自定义网络下默认就可以使用容器名进行容器的互联，内部已经维护好了容器名和 ip 的对应关系

1 2	# 在 redis1 容器中访问 redis2 容器 sudo docker exec -it redis1 ping redis2

注：默认的 bridge 网络不支持通过容器名进行互联

默认情况下两个网络是隔离的，如果需要让两个网络下的容器能够互相访问，可以使用network connect命令将容器连接到另一个网络

在默认的 bridge 网络下创建一个 redis3 容器用于演示

1	sudo docker run -it -d -P --name redis3 --net bridge redis:alpine

默认情况下，两个不同网络的容器无法访问

将 redis3 容器加入到 mynet 网络中

1 2	# docker network connect 网络名或id 容器名或id sudo docker network connect mynet redis3

加入后就可以成功访问了

查看 mynet 网络信息和 ip 信息后发现，redis3 容器被分配了一个 mynet 的网络接口和 ip 地址

Linux 同步机制之原子操作

2021-05-17T15:30:58.000Z

使用原子操作典型例子众所周知就是多个线程操作同一个全局变量 i++, 由于对应的汇编指令并不只是一条，在并发访问下可能出现多个线程中的多条指令交错导致部分加操作丢失。全局变量i属于临界资源，当然可以使用加锁的方式保护临界资源，但是加锁开销比较大，用在这里有些杀鸡焉用牛刀。最好的方式是使用内核提供的atomic_t类型的原子变量来进行原子操作。

笔者本次通过源码来窥探原子操作的底层实现, 本次仍以 arm 架构下的 kernel 2.6.35 版本为源码来源。

首先来看下atomic_t的定义, 仅仅只是一个int类型变量

include/linux/types.h

1
2
3

typedef struct {
    int counter;
} atomic_t;

以原子加操作为例, 来看下atomic_add的实现

arch/arm/include/asm/atomic.h

static inline void atomic_add(int i, atomic_t *v)
{
    unsigned long tmp;
    int result;

    __asm__ __volatile__("@ atomic_add\n"
"1: ldrex   %0, [%3]\n"
"   add %0, %0, %4\n"
"   strex   %1, %0, [%3]\n"
"   teq %1, #0\n" 
"   bne 1b"
    : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
    : "r" (&v->counter), "Ir" (i)
    : "cc");
}

先对以上需要用到的内嵌汇编知识做一个简单介绍。
内嵌汇编的格式如下:

__asm__ volatile(
    instruction
    : output
    : intput
    : changed);

instruction 部分便是要执行的汇编指令
input 部分为汇编指令需要执行的输入, 表示将 c语言定义的值传入汇编
output 部分为汇编指令执行的输出，表示将汇编执行后的值传给 c语言
change 部分用于告诉 gcc 该内嵌汇编改变了一些值，强迫 gcc 在编译这段内嵌汇编之前保存会被修改的值，在执行完后恢复

内嵌汇编中引用 input 部分和 output 部分的值使用 %0, %1, %2 … 占位符, 也就是上述代码中的 result 为 %0, tmp 为 %1, v->counter 为 %2, &v->counte 为 %3, i 为 %4。
除此每个变量都以 “xx”(yy) 形式出现, 其中”xx”部分为修饰, 以下列出理解atomic_add需要用到的修饰，其他可忽略

“=&r”: = 表示只写, & 表示仅用作输出, r 使用任何可用的寄存器
“+Qo”: + 表示可读可写

atomic_add的核心是两条关键的汇编指令, ldrex和strex需要配套使用

// 将寄存器 ry 指向的内存值 load 到寄存器 rx 中， 并记录 ry 指向的内存状态为 exclusive(独占的)
ldrex rx, [ry]

// strex 更新内存时，会检查内存 exclusive 状态
// 将寄存器 ry 的值 store 到 rz 指向的内存，如果指向的内存为 exclusive, 则执行成功，否则失败。
// 成功则寄存器 rx 被设置为 0, 否则设置为 1。执行成功后清除 exclusive 标记 (清除后可以认为标记为 open)
strex rx, ry, [rz]

铺垫完上述前提知识后, 以下给出对汇编代码的逐行注释

static inline void atomic_add(int i, atomic_t *v)
{
    unsigned long tmp;
    int result;

    __asm__ __volatile__("@ atomic_add\n"  // @ 为注释
"1: ldrex   %0, [%3]\n"         // 把 v->counter 内存值 load 到 result 中   (v->counter 内存会被记录为 exclusive)
"   add %0, %0, %4\n"           // result += i
"   strex   %1, %0, [%3]\n"     // 把 result 的值 store 到 v->counter 的内存，并把 store 成功与否存入 tmp
"   teq %1, #0\n"               // tmp 为 0 表示成功
"   bne 1b"                     // 如果不为 0， 则重新执行一遍
    : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
    : "r" (&v->counter), "Ir" (i)
    : "cc");   // condition register, 状态寄存器标志位
}

考虑这样的一种 case 来帮助理解, 假设有两个 cpu 发起对同一段内存的访问
1.CPU1 发起 ldrex 读操作, 记录当前状态为 exclusive
2.CPU2 发起 ldrex 读操作, 记录当前状态为 exclusive, 状态保持不变
3.CPU2 发起 strex 写操作, 状态从 exclusive 变为 open, 同时数据写回内存
4.CPU1 发起 strex 写操作, 由于当前状态为 open, 则写失败
5.CPU1 由于 strex 写失败, 根据atomic_add的"teq %1, #0\n" "bne 1b"逻辑会再进行 ldrex 后 strex 直到成功(这就是所谓的自旋), 所以保证了每一个加操作都不会丢失

arm 的 exclusive 标记是通过 exclusive monitor 模块实现的，在老的 x86 架构下实现类似 ldrex/strex 功能会通过锁总线实现导致效率低下

AF_XDP socket 介绍

2021-05-07T17:29:06.000Z

eBPF

eBPF 相当于在内核中有一个运行特定字节码的虚拟机，可以动态将 eBPF 字节码注入进内核。eBPF 程序会 attach 到指定的内核代码路径中，当执行到该代码路径时，会执行对应的 eBPF 程序

XDP

XDP 是专门针对于网络数据，是基于 eBPF 的高性能数据链路。可以在以下三种模式运行：

Native：工作在网络驱动早期接收队列上
Offload：直接运行在网卡中，需要特定的智能网卡支持
Generic：对于不能支持 Native 和 Offload 模式下，内核提供一种通用模式。该模式运行在网络协议栈处理早期，不需要特定网卡支持，但性能会远低于以上两种模式
XDP 对每个报文的处理称之为 action，支持以下action：
DROP：在驱动层直接丢弃数据包，通常用于丢弃 DDos 攻击报文
PASS：允许数据包进入协议栈处理，之后数据包的处理就跟传统的处理方式一样
TX：可将报文从接收到该报文的 NIC 发送出去
REDIRECT：与 TX 模式一样，但是重定向到另一个 NIC 发送出去，或可以将数据包重定向到 AF_XDP socket 的用户空间程序 mmap 映射的内存中
ABORTED：表示程序发生了异常，效果与 DROP 一样，但可以在用户空间来监控这种异常发生

AF_XDP

区别于传统 socket 数据流经内核协议栈的方式，XDP 程序在网卡驱动中直接取得网卡收到的数据包，然后直接送到用户态应用程序

应用程序利用 AF_XDP 协议族的 socket 接收数据。 XDP 程序会把数据帧送到一个在用户态可以读写的内存中，用户态应可在该内存中直接完成数据包的读取和写入，整个过程是完全 zero copy

UMEM

使用 XDP socket 之前，需要在用户态通过 mmap 创建一段用户空间的内存，称之为 UMEM。这是一段连续的内存，被分割为若干个相同大小的 frame，每个 frame 可容纳一个数据包。

通过 socket 系统调用创建 AF_XDP socket，创建之后每个 socket 都各自分配了一个 RX ring 和 TX ring。这两个 ring 需要通过 socket 选项 XDP_RX_RING 和 XDP_TX_RING 进行注册。每个 socket 必须至少具有其中一个ring。RX 或 TX ring 存储着描述符集合，每个描述符指向 UMEM 中的一个 frame，描述符通过引用 frame 在 UMEM 中的偏移量来引用 frame。RX 和 TX 可以共享相同的UMEM，所以一个报文无需在 RX 和 TX 之间进行拷贝。

UMEM 也包含两个 ring：Filling ring 和 Completion ring。应用程序会使用 Fill ring 下发描述符，让内核填写 RX 包数据后发送，一旦接收到报文，就绪的描述符也会被填入 RX ring，可以在用户态使用 poll来等待就绪描述符的到来。通过写入 Completion ring，通知内核有一个或多个数据包已经就绪，请求内核进行数据发送。

上古神器 awk 笔记

2021-05-01T18:51:25.000Z

`awk`基本格式

1	awk '{ awk program }' file

file 为 awk 要读取的文件，可以是一个或多个文件。如果不指定文件，则从标准输入中读取
1
awk '{ awk program }' a.txt b.txt c.txt
单引号内的是awk的程序，一般使用单引号而非双引号。 awk是按行处理文件，内部有一个隐藏的循环，即默认下逐行读取文件并运行程序
使用单引号原因：双引号中的$会被 shell 解析成 shell 变量引用，于是会进行 shell 变量替换。为了表示awk程序使用的变量，所以尽可能使用单引号

awk 程序中的 {} 表示代码块

1 2	awk '{print $0}' a.txt awk '{print $0}{print $0; print $0}' a.txt

`BEGIN` 和 `END` 语句块

1	awk 'BEGIN{print "俺要开始读文件啦"}{print $0}END{print "俺处理完文件啦"}' a.txt

BEGIN 代码块: 在读取文件前行执行一次，不参与awk的隐藏循环
END 代码块：在读取文件完成后执行一次，不参与awk的隐藏循环
main 代码块：不以BEGIN或END开头的代码块都称之为 main 代码块， main 代码块会参与 awk 的隐藏循环

`awk`pattern 和 action

awk '
BEGIN {
    n=3
}
/^[0-9]/ {
    print $1
}
END {
    print "end"
}
' a.txt

awk语法格式为pattern { action }模式，称之为awkrule

pattern 用于筛选符合的文本行
action 表示筛选通过后执行的操作
pattern 和 action 都可省略
- 省略 pattern 则不筛选数据，表示对每一行数据都执行 action
- 省略 {action} 表示对每一行都执行 {print}
- 省略 action 表示对筛选的行不做任何操作，该语法实际使用中并无意义

可以将 BEGIN 与 END 代码块看成一种特殊的 pattern{action} 代码块

# bool pattern
/regular expression/   # 正则匹配，e.g., /a.*ef/{action}
relational expression  # 大小关系匹配，e.g., 3>2{action}
pattern && pattern     # 逻辑与
pattern || pattern     # 逻辑或
!pattern               # 逻辑反
pattern ? pattern : pattern  # 三目运算符

# 范围 pattern
pattern1, pattern2     # 范围匹配，匹配从 pattern1 到 pattern2 之间的内容

`awk` 读取文件

记录分隔符

awk读取文件时，每读取一条记录(Record)(默认下按行读取，一行就是一条记录). 每读取一条记录，将其保存到$0中，然后执行一次 main 代码段。

可通过修改预定义变量RS来改变每次读取的记录模式，RS变量表示输入记录分隔符(Record Separator)，默认值为\n

RS一般设置在 BEGIN 代码块中，因为需要在读取文件前确定好分隔符

注：RS变量作为输入记录分割符，所读取的每条记录不包含RS变量值

RS 为单个字符，则直接用该字符来分割记录
RS 为多个字符，则将其作为正则表达式，只要匹配上正则表达式都用来分割记录
- 设置预定义变量IGNORECASE为非零值，正则匹配时忽略大小写

特殊RS值解决特定需求：

1
2
3

RS=""    # 按段落读取
RS="^$"  # 一次性读取所有数据, 该正则只能匹配空文件
RS="\n+" # 按行读取，但忽略所有空行

awk每读取一条记录时，会设置预定义变量RT表示记录分割符(Record Termination)。当RS为单个字符时，RT的值和RS值相同。当RS为正则表达式时，RT`为正则匹配的记录分隔符

行号

awk读取每条记录后，将其赋值给$0和设置RT外，还会设置NR和FNR这两个预定义变量

NR: 所有文件的行号计数器
FNR: 各个文件的行号计数器，针对于多个文件输入的情况

字段分割

awk读取每条记录后，将其赋值给$0，同时还会对该条记录按照预定义变量FS划分字段，将划分后的各个字段依次存入$1，$2，$3 …，同时将划分好的字段数量赋值给预定义变量NF

1	awk '{print $NF}' a.txt # 输出 a.txt 的最后一列

未完待续 ~~

内核链表介绍

2020-07-31T07:49:22.000Z

应要求分享一下内核链表结构，故写了本blog。本文对内核链表做一个简单介绍，以及引出内核中大量使用的分离思想和数据结构的定义。

传统链表的困境

内核中数据结构千变万化，采用传统的链表结构形式，需要为各种数据都定义出一个链表。

/* data1 */
struct data1_list_node {
    struct data1 data;
    struct data1_list_node *next;
    struct data1_list_node *prev;
}

/* data2 */
struct data2_list_node {
    struct data2 data;
    struct data2_list_node *next;
    struct data2_list_node *prev;
}

/* data3 */
/* ... */

以上会出现大量定义链表结构，而在c++的模板语法下，可以定义一个链表模板来解决这个问题

template <typename T>
struct list_node {
    T data;
    ListNode *next;
    ListNode *prev;
};

list_node<struct data1> data1_head;
list_node<struct data2> data2_head;
/* data3 */
/* ... */

数据和结构分离

问题的核心在于数据的千变万化，但是所要表述的结构却是统一的！那如果将统一的部分抽取出来呢？让一切的一切都尘归尘，土归土。

内核链表

内核链表正是采用了如上的思想进行设计的，内核链表位于内核代码的include/linux/list.h中，该链表定义为双向循环链表，所有的相关操作都定义在该头文件中，该文件中每个函数极为简洁。截取片段如下

struct list_head {
    struct list_head *next；
    struct list_head *prev;
};

#define LIST_HEAD_INIT(name) { &(name), &(name) }

#define LIST_HEAD(name) \
struct list_head name = LIST_HEAD_INIT(name)

static inline void __list_add(struct list_head *new,
      struct list_head *prev,
      struct list_head *next)
{
    next->prev = new;
    new->next = next;
    new->prev = prev;
    prev->next = new;
}

static inline void list_add(struct list_head *new, struct list_head *head)
{
__list_add(new, head, head->next);
}

使用内核链表的方式，将链表节点嵌入到数据结构体中。如内核驱动中对misc设备的描述

struct miscdevice  {
    int minor;
    const char *name;
    const struct file_operations *fops;
    struct list_head list;    /* 用内核链表管理所有注册在内核中的misc设备 */
    struct device *parent;
    struct device *this_device;
    const char *nodename;
    mode_t mode;
};

核心问题：通过遍历所有的struct list_head即可拿到所有数据的list成员，而真正需要的是数据，那么如何从list成员获取到struct miscdevice, 最直接的做法是将list成员放置在struct miscdevice最开始处，只需指针强转即可获得，而如上所知该成员并未放到结构体的最开头，内核中的做法是可以放在任意位置，解析时使用了一个很强大的宏来进行获取。

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

#define container_of(ptr, type, member) ({    \
const typeof( ((type *)0)->member ) *__mptr = (ptr);    \ /* 1 */
(type *)( (char *)__mptr - offsetof(type,member) );})     /* 2 */

/* 上面 typeof 为 GNU gcc 扩展语法，可用来获取一个变量的类型 */
/* 以上1代码去掉后，将2中的 __mptr替换为ptr也可正常工作。看似无用，实则用于编译期间类型检查 */
/*******************************************************************/
#define list_entry(ptr, type, member) \
container_of(ptr, type, member)

#define list_first_entry(ptr, type, member) \
list_entry((ptr)->next, type, member)

#define list_next_entry(pos, member) \
list_entry((pos)->member.next, typeof(*(pos)), member)

/* 内核链表的遍历接口 */
#define list_for_each_entry(pos, head, member)\
for (pos = list_first_entry(head, typeof(*pos), member);\
     &pos->member != (head);\
     pos = list_next_entry(pos, member))

总结

内核中大量使用了该思想，凡是在物理内存中离散分布的结构，均采用此思想将结构嵌入到具体数据中实现数据的结构组织，例如在 epoll 底层和进程调度使用到的 rbtree 。

struct rb_node {
    unsigned long  __rb_parent_color;   /* 包含 parent 指针以及 color 信息 */
    struct rb_node *rb_right;
    struct rb_node *rb_left;
} __attribute__((aligned(sizeof(long))));

在总线设备驱动模型中，除了纵向的分层外还有横向的数据分离。包括设备和驱动的分离、主机和外设驱动的分离。

OpenResty入门笔记

2020-06-03T17:34:04.000Z

OpenResty 简介

OpenResty 是一个高性能 Web 平台，打包了标准的 Nginx 核心，集成了很多常用的第三方模块。简单理解，OpenResty 是 Nginx 的加强。

安装

安装方法跟 Nginx 基本一致，笔者采用的是 Ubuntu 20.04 的环境。

安装依赖库

1
2
3

sudo apt install libpcre3-dev    # pcre库: 解析正则表达式
sudo apt install libz-dev        # zlib库: 压缩/解压缩功能
sudo apt install libssl-dev      # openssl库: ssl功能相关库，用于网站加密通讯

下载源码并解压

1 2	wget https://openresty.org/download/openresty-1.15.8.3.tar.gz tar xvf openresty-1.15.8.3.tar.gz

编译安装

1
2
3

cd openresty-1.15.8.3
./configure
make -j4 && sudo make install

安装完后的路径位于/usr/local/openresty/下，可以看到bin/openresty 指向的正是 nginx

为了方便使用，可将/usr/local/openresty/bin加入到环境变量中，在~/.bashrc或~/.zshrc中添加

1	export PATH=/usr/local/openresty/bin:$PATH

启停

启动和停止命令跟 Nginx 一致

# 启动
sudo /usr/local/openresty/bin/openresty
# 停止
sudo /usr/local/openresty/bin/openresty -s stop
# 热重启
sudo /usr/local/openresty/bin/openresty -s reload

opm常用命令

node.js 有 npm 包管理工具，openresy 同样也有一个类似工具叫 opm

/usr/local/openresty/bin/opm list        # 列出当前已安装的组件
/usr/local/openresty/bin/opm search http # 以关键字检索相关组件
sudo /usr/local/openresty/bin/opm get ledgetech/lua-resty-http   # 安装组件
/usr/local/openresty/bin/opm info ledgetech/lua-resty-http       # 查看已安装组件信息
sudo /usr/local/openresty/bin/opm ledgetech/lua-resty-http       # 移除组件
sudo /usr/local/openresty/bin/opm ledgetech/lua-resty-http       # 更新已安装组件
sudo /usr/local/openresty/bin/opm update                         # 更新所有安装组件

参考手册

1 2	/usr/local/openresty/bin/restydoc nginx # 查看nginx说明 /usr/local/openresty/bin/restydoc -s proxy_pass # -s 查看手册里小节

稍后补充剩下内容QAQ

rk3399-android9.0-secureboot介绍

2020-01-09T11:58:04.000Z

RK完整的Secureboot包括两部分，第一部分为Linux的Secureboot，第二部分为Android特有的AVB（Android Verified Boot）。开启了Secureboot的设备，会在启动时逐级校验各分区，一旦某一级校验不通过，则设备就无法启动。

Secureboot分为安全性校验与完整性校验。

安全性校验: 为公钥的校验，借助于芯片的一次性可编程安全存储模块（OTP 或 efuse）, 在rk3399上称为efuse。该检验流程为从efuse中读取公钥 hash，与计算的公钥 hash 先做对比，如果相同，则再将公钥用于解密固件 hash。
完整性校验: 为校验固件的完整性，计算固件的 hash 与用公钥解密出来的 hash 对比是否一致。

AVB阶段安全性校验和完整性校验需要依赖于vbmeta.img，相关的公钥及描述信息存储在vbmeta.img中。

Secureboot流程

Secureboot涉及到的两级：maskrom —> miniloader、miniloader —> uboot、uboot—> kernel，但在Android上Secureboot部分只实现前两级，uboot—> kernel以及之后的启动校验交由AVB进行处理。以下以maskrom —> miniloader为例讲解Secureboot流程。

pc加密过程

使用rk提供的签名工具（rk_sign_tool）进行签名步骤及原理如下

1.该工具首先会产生一对密钥对，即：public key和privete key

2.使用SHA256计算镜像的hash，并使用privete key对镜像的hash进行RSA2048签名

3.使用SHA256计算出public key的hash

4.将镜像+第2步中签名+public key进行打包形成新的镜像

5.第3步中的hash将会烧写到efuse中

设备解密过程

1.首先从新的镜像中获取public key计算hash值

2.从efuse中读取public key的hash值进行对比，如果相同则继续，否则启动失败

3.从镜像中获取签名，然后使用RSA2048计算hash

4.使用SHA256计算镜像的hash值，与第三步计算出来的hash进行对比，相同则继续，否则启动失败

AVB流程

AVB的核心结构为vbmeta，vbmeta分区存储了boot分区的hash，而对于system和vender分区，哈希树紧随在各自的分区数据之后，vbmeta分区只保存哈希树描述符中哈希树的根哈希(root hash)，盐(salt)和偏移量(offset)。

uboot启动后，首先需要进行vbmeta的合法性验证，即安全性校验，RK的做法是将验证vbmeta的公钥信息经过trust加密后存储在security分区，其中trust分区的安全性又是受efuse验证的Secureboot进行保证的。uboot启动kernel前先验签vbmeta，vbmeta可信后，再取出vbmeta中的相关信息来进行其他分区的校验。

Merkle Tree

hash list

AVB在验证system分区时采用了动态校验的方式进行完整性校验，所以采用了分块进行hash的方式来校验。那么如何存储该数据块的hash，直接采用最暴力的方式，自然而然想到的是使用一个hash列表来存储。但是使用Hash列表来保证数据块的正确性还不够，黑客修改数据的同时，如果将Hash列表也对应修改了，这就无法保证数据块的正确性了。所以需要引入一个顶层的hash，将hash列表里的每个hash字符串拼在一起后再做一次hash运算，最后的hash值称之为root hash，只要保证该root hash的正确性即可。

但是AVB并未采用该简单结构。假设system的大小为1GB，数据块大小为4KB，则有26万个数据块，对应着hash列表就有26万个元素。AVB进行运行时校验，设备运行时读到哪个块就会对哪个块校验，将需要校验的块进行hash后更新具有26万个元素的hash列表中的一个元素后计算root hash，再与vbmeta中root hash作对比来判断数据是否正确。这个效率可想而知非常糟糕，所以AVB采用了一种称为Merkle Tree的树结构。

hash tree

Merkle Tree，通常也被称作Hash Tree，其叶子节点是数据块或者文件的hash值。非叶节点是其对应子节点串联字符串的hash。Hash 列表可以看作一种特殊的Merkle Tree，即树高为2的多叉Merkle Tree。

建树过程：
在树的最底层，和hash列表一样，将数据分成若干个小的数据块，有相应的hash与之对应。但是往上走，并不是直接去计算root hash，而是把相邻的两个hash合并成一个字符串，然后计算这个字符串的hash，将这个hash值作为两个节点的父节点。按照同样的方式，可以得到数目更少的新一级hash，最终必然形成一棵树，树的根节点即为root hash。

Merkle Tree的结构非常易于同步大文件或文件集合，按照查找树的查找思路，从root hash开始比对，依次往下查找到叶子节点即能找到需要重新同步或下载的数据块，其时间复杂度为O(logN)，如果采用hash列表的方式，需要完整进行一遍遍历才能定位到不同的数据块，其时间复杂度为O(N)。Merkle Tree在数字签名、P2P网络、区块链等技术都有应用。回到本文介绍的AVB，AVB在运行时校验某一块时只需要更新Merkle Tree的一个分支即可计算出hash root，其运算时间比hash列表大大减少。在Android9上使用avbtool的python代码进行hash tree的生成，该算法跟上文描述略有不同，当1G的system进行4KB大小的划分，其生成的hash tree只有四层(包括root hash这一层)，所以运行时计算hash只要沿着这个四层树的分支计算即可，可想而知效率大大提升。

avbtool中建树源码分析

以下分析一下Android9上hash tree的生成过程，涉及到用Python实现的avbtool源码的两个函数：calc_hash_level_offsets，generate_hash_tree

calc_hash_level_offsets

def calc_hash_level_offsets(image_size, block_size, digest_size):
  """Calculate the offsets of all the hash-levels in a Merkle-tree.

  Arguments:
    image_size: The size of the image to calculate a Merkle-tree for.
    block_size: The block size, e.g. 4096.
    digest_size: The size of each hash, e.g. 32 for SHA-256.

  Returns:
    A tuple where the first argument is an array of offsets and the
    second is size of the tree, in bytes.
  """
  level_offsets = []  # 用来存储每一层在bytearray中的偏移
  level_sizes = []    # 每一层占用的大小
  tree_size = 0       # 树的大小

  num_levels = 0      # 树的层数
  # size用于计算时表示当前层的下一层的数据大小，从第0层（计算数据块hash）开始，
  # 所以初始值为image的大小
  size = image_size   
  while size > block_size:
    # 计算当前层数据需要多少个块
    num_blocks = (size + block_size - 1) / block_size
    # round_to_multiple函数用来将第一个参数舍入到最接近第二个参数的倍数
    # 在这里就是对齐到block_size的整数倍
    # 计算当前层的hash digest需要占用的大小
    level_size = round_to_multiple(num_blocks * digest_size, block_size)

    level_sizes.append(level_size)
    tree_size += level_size
    num_levels += 1

    # 循环往上计算，所以更新size为当前层，用于计算上一层
    size = level_size

  # 计算每一层在bytearray中的偏移  
  for n in range(0, num_levels):
    offset = 0
    for m in range(n + 1, num_levels):
      offset += level_sizes[m]
    level_offsets.append(offset)

  return level_offsets, tree_size

Android9上将hash tree存储在bytearray中，所以需要事先计算好树的每一层在bytearray中的偏移，以及整个树需要多长的bytearray存储。注意，hash tree的建树过程上自下往上的。其实从calc_hash_level_offsets函数就可大致看出Android上hash tree的存储形态了，但更为形象的存储结构还是需要看generate_hash_tree函数。

generate_hash_tree

def generate_hash_tree(image, image_size, block_size, hash_alg_name, salt,
                       digest_padding, hash_level_offsets, tree_size):
  """Generates a Merkle-tree for a file.

  Args:
    image: The image, as a file.
    image_size: The size of the image.
    block_size: The block size, e.g. 4096.
    hash_alg_name: The hash algorithm, e.g. 'sha256' or 'sha1'.
    salt: The salt to use.
    digest_padding: The padding for each digest.
    hash_level_offsets: The offsets from calc_hash_level_offsets().
    tree_size: The size of the tree, in number of bytes.

  Returns:
    A tuple where the first element is the top-level hash and the
    second element is the hash-tree.
  """
  hash_ret = bytearray(tree_size)
  hash_src_offset = 0
  hash_src_size = image_size
  level_num = 0
  while hash_src_size > block_size:
    level_output = ''
    remaining = hash_src_size
    while remaining > 0:
      hasher = hashlib.new(name=hash_alg_name, string=salt)
      # Only read from the file for the first level - for subsequent
      # levels, access the array we're building.
      # 第0层直接按照block_size读取image来进行hash
      if level_num == 0:
        image.seek(hash_src_offset + hash_src_size - remaining)
        data = image.read(min(remaining, block_size))
      # 第0层之上的每一层都由取其下一层来进行hash，eg: 将第m-1层的数据分块hash后生成m层数据
      else:
        offset = hash_level_offsets[level_num - 1] + hash_src_size - remaining
        # 以block_size为单位进行分块
        data = hash_ret[offset:offset + block_size]
      hasher.update(data)

      remaining -= len(data)
      if len(data) < block_size:
        hasher.update('\0' * (block_size - len(data)))
      level_output += hasher.digest()
      if digest_padding > 0:
        level_output += '\0' * digest_padding

    padding_needed = (round_to_multiple(
        len(level_output), block_size) - len(level_output))
    level_output += '\0' * padding_needed

    # Copy level-output into resulting tree.
    offset = hash_level_offsets[level_num]
    hash_ret[offset:offset + len(level_output)] = level_output

    # Continue on to the next level.
    hash_src_size = len(level_output)
    level_num += 1

  # 建树完成后，单独计算root hash
  hasher = hashlib.new(name=hash_alg_name, string=salt)
  hasher.update(level_output)
  return hasher.digest(), hash_ret

通过calc_hash_level_offsets函数计算好偏移和大小后，即可将参数传递给generate_hash_tree函数来建树了。从建树代码的循环过程可以看出，该树的实现是将生成的hash拼接在一起作为这一层的数据，然后分块进行hash后再拼接在一起给到父层，而不是之前的描述Merkle Tree的两两子节点合并后计算hash作为父节点。

Express入门笔记

2019-11-21T14:10:32.000Z

Node.js简述

Node.js是基于chrome浏览器中的v8引擎而构建的js运行时环境, 并提供了一系列的工具模块和一个包管理工具npm. Node脱离于浏览器运行, 并提供了一系列自带的os相关接口, 从而使其能像传统后端语言一样操作文件、获取os相关信息等.

安装

sudo apt-get install nodejs         # 安装nodejs
sudo apt-get install npm            # 安装npm (node package manager)
node -v                             # 查看node版本
npm -v                              # 查看npm版本

npm常用命令

npm help                             # 查看帮助
npm 命令 help
npm config list                      # 查看npm配置信息
npm install --global npm             # 升级npm
npm init                             # 初始化项目(生成package.json文件)      
npm install                          # 根据package.json文件下载安装所有node依赖包
npm install 包名                      # 下载安装node包
npm install 包名@x.x.x                # 下载安装指定版本的node包
npm install 包名 --save               # 下载安装node包且保存依赖性到package.json中
npm uninstall 包名                    # 卸载node包, 保留package.json中的依赖性
npm uninstall 包名 --save             # 卸载node包并清除package.json中的依赖性

安装使用cnpm

npm会去国外服务器下载包, 淘宝在国内做了完整的npmjs.org镜像, 可以用cnpm代替npm下载包.

# 安装cnpm
sudo npm install --global cnpm

# 之后使用cnpm代替npm进行install
cnpm install 包名

或者仍然使用npm, 但指定使用淘宝的镜像源进行下载

# 每次下载都指定--registry参数
npm install 包名 --registry=https://registry.npm.taobao.org

# 或者直接将该选项加入配置文件中
npm config set registry https://registry.npm.taobao.org

模块

Node.js中的模块概念, 类似于python中的模块, 一个js文件即是一个模块.

加载模块

通过require函数加载模块, 加载模块时会去执行模块内的代码. Node.js加载模块跟python一样, 只有第一次加载时会去执行模块内的代码后将其加载到内存中, 随后再去加载仅仅是将在内存中存在的模块增加一次引用而已, 并不会再去执行模块内代码.

// 加载自定义模块, 一个js文件就是一个模块, 去掉后缀名即模块名
const myModule = require('./cai.js')      // 加载当前路径下的cai模块
const myModlue  = require('./cai')        // 与上一句等价

// 加载内置模块: 当require参数不含路径时, 表示加载内置模块
const fs = require('fs')          // 加载file system模块
const http = require('http')      // 加载http模块

对外导出变量

Node.js是模块作用域, 各模块之间相互隔离, 如果需要将模块内变量暴露出去, 则需要通过node的内置对象module.exports导出. require函数的返回值即是导入的模块的module.exports对象.

cai.js

const add = function(a, b) {
    return a + b
} 

let str = 'hello world'

// 通过exports对象导出add函数和str变量
module.exports.add = add
module.exports.str = str

hello.js

// require返回值即是cai.js中的module.exports对象
const cai = require('./cai')
 
// 通过module.exports对象即可访问到cai模块中的add函数和str变量
let res = cai.add(1, 2)
console.log(res)
console.log(cai.str)

注: 为了使用方便, node内置exports = module.exports, 所以也可以使用exports对象暴露, 但如果需要让require函数返回自定义值, 则必须向module.exports赋值而不是exports

Express

express是基于node.js的web框架, 是node.js的一个第三方模块.

安装

1	npm install express --save

server demo

express_demo.js

const express = require('express')
const path = require('path')
                 
const app = express()
                 
/* 开放静态资源 */                                                                        
// 127.0.0.1/public/xxx
app.use('/public', express.static(path.join(__dirname, './public')))
// 127.0.0.1/xxx
//app.use(express.static(path.join(__dirname, './public')))

/*
 * 响应get请求
 * req: request 请求
 * res: response 响应
 */
app.get('/', (req, res) => {
    // 通过send方法向浏览器返回响应
    res.status(200).send('hello express!')
}) 

/*
 * 响应post请求
 * req: request 请求
 * res: response 响应
 */
app.post('/login', (req, res) => {
    //   通过json方法向浏览器返回Json数据
    res.status(200).json({
        error: 0,
        msg: 'login success',
    })
})
  
/* 运行服务器, 监听80端口 */
app.listen(80, () => {
    console.log('server is running, listening port 80 ...')
})

运行server

1	sudo node express_demo.js

每次修改代码都要重新运行, 解决方法是用nodemon代替node运行js代码

# 安装nodemon
sudo npm install --global nodemon
# 运行server
sudo nodemon express_demo.js

模板引擎art-template

art-template语法

安装

1 2	npm install --save art-template npm install --save express-art-template

配置使用

const express = require('express')

const app = express()

// 只需这一行配置就可使用express-art-template, 第一个参数为模板文件的后缀名
//app.engine('art', require('express-art-template'))
app.engine('html', require('express-art-template'))

// express-art-template默认去当前项目的views目录寻找模板文件
// 如果需要更改该默认路径, 使用下面这一行代码
//app.set('views', path.join(__dirname, './views))

app.get('/', (req, res) => {
    // 调用render方法渲染模板, 并向模板传递模板对象, expres会自动填充模板变量
    res.render('index.html', {
        title: 'index'
    })
})

app.listen(80, () => {
    console.log('server is running, listening port 80 ...')
})

中间件

**中间件(middleware)**是介于请求到响应的整个流程的一道过程, express中使用app.use方法注册中间件, 每个中间件是一个回调函数, 接收三个参数, 依次为request、response、next回调函数(代表下一个中间件). 在中间件中调用next函数则会将request和response传递给下一个中间件.

const express = require('express')
        
const app = express()
 
// 通过use方法注册中间件
app.use((req, res, next) => {
    console.log('the first middleware')
    // 调用下一个中间件
    next()
})   
        
app.use((req, res, next) => {
    console.log('the second middleware')
    next()
})   
        
app.get('/', (req, res) => {
    console.log('get /')                                                                
    res.status(200).send('middleware demo')
})   
        
app.listen(80, () => {
      console.log('server is running, listening port 80 ...')
})

运行后, 访问127.0.0.1, 控制台输出以下内容

server is running, listening port 80 ...
the first middleware
the second middleware
get /

中间件默认对所有url进行处理, 如果需要对特定的url进行处理, 可以通过req.url参数来判断

app.use((req, res, next) => {
    if (req.url === '/') {
            console.log('the first middleware')
            // 调用下一个中间件
            next()
    }
})

除了通过request对象来获取url外, app.use方法允许接收一个url字符串作为第一个参数

app.use('/', (req, res, next) => {
    console.log('the first middleware')
    // 调用下一个中间件
    next()
})

获取请求参数

get请求的参数可以通过req.query获取

app.get('/login', (req, res) => {
    /* 通过req.query获取get请求时url的参数, 获取的是key-value形式的object */
    console.log(req.query)
    /* res.send方法向浏览器返回响应 */
    res.send('login cuccessful !')
})

而post请求, 在express中没有内置获取post请求参数的api, 需要使用第三方模块body-parser作为中间件进行注册.

body-parser文档

安装

1	npm install body-parser --save

配置使用

const express = require('express')
// 加载body-parser模块
const bodyParser = require('body-parser')

const app = express()

/* 配置body-parser */
app.use(bodyParser.urlencoded({ extended: false }))
app.use(bodyParser.json())

app.post('/login', (req, res) = > {
    /* 通过req.body获取post请求的参数, 获取的是key-value形式的object */
    consloe.log(req.body)
    /* res.send方法向浏览器返回响应 */
    res.send('login cuccessful !')
})

app.listen(80, () => {
    console.log('server is running, listening port 80 ...')
})

路由模块化

可以将路由相关代码从主入口文件中单独抽离出来, 然后在主入口文件中引用.

router.js

const express = require('express')

const router = express.Router()

router.get('/', (req, res) => {
   res.render('index.html')
})

router.get('/login', (req, res) => {
   res.render('login.html')
})

// ......

module.exports = router

app.js

const express = require('express')
// 加载路由
const router = require('./router.js')

const app = express()  

app.engine('html', require('express-art-template'))

// 使用路由
app.use(router)

app.listen(80, () => {
    console.log('Server is running ...')
})

状态保持

在express中默认不支持Cookie和Session, 需要通过第三方模块express-session解决.

安装

1 2	npm instlal cookie-parser --save npm install express-session --save

配置

const express = require('express')
const cookieParser = require('cookie-parser');  
const session = require('express-session')

const app = express()

// 配置cookie
app.use(cookieParser())
// 配置session
app.use(session({
  secret: 'keyboard cat', 
  resave: false,
  saveUninitialized: true,
  cookie: { secure: true }
}))

使用

// 设置cookie, maxAge为过期时间, 以ms为单位
res.cookie('username', 'caicai', { maxAge: 7 * 24 * 3600 * 1000, httpOnly: true});

// 获取cookie
res.cookies.username

// 删除cookie
res.clearCookie('username')

// 设置session
req.session.passwd = 'xixixi'
    
// 获取session
req.session.passwd

// 删除session
delete req.session.passwd

SELinux之解决avc denied

2019-11-18T09:04:01.000Z

SELinux简述

安全增强型 Linux（Security-Enhanced Linux）简称 SELinux，它是 Linux 的一个安全子系统。SELinux 主要作用是最大限度地减小系统中服务进程可访问的资源（最小权限原则）。对资源的访问控制分为两类: DAC和MAC.

DAC

在未使用SELinux的系统上, 对资源的访问是通过权限位来确定, 比如一个文件对所属用户是否有读、写、执行权限, 其他用户的访问可由所属用户进行配置. 这种由所属用户自己决定是否将资源的访问权或部分访问权授予其他用户，这种控制方式是自主的，即自主访问控制（Discretionary Access Control, DAC）.

1 2	> ls -l note -rw-rw-r-- 1 ifantsai ifantsai 37 6月 17 13:36 note

MAC

在使用了 SELinux 的系统上，对资源的访问除了通过权限位判定外，还需要判断每一类进程是否拥有对某一类资源的访问权限。这种方式对资源的访问控制, 称之为强制访问控制（Mandatory Access Control, MAC）.只给每个进程开放所需要的资源, 将权限开放到最小, 当进程出现漏洞时也只会影响到该进程所涉及的资源, 这大大提升了安全性.

SELinux工作模式

SELinux 有三种工作模式，分别为:

enforcing: 强制模式, 执行SELinux规则, 违反的行为会被阻止
permissive: 宽容模式, 执行SELinux规则, 违反的行不会被阻止
disabled: 关闭SELinux

通过执行getenforce命令可以获取当前SELinux的工作模式

在Android系统开发中, 可能会遇到SELinux的权限不足而引起的各种问题. 可以尝试将SELinux工作模式临时改为宽容模式看问题是否解决, 来判定是否是SELinux引起的问题.

1 2	# 修改工作模式为宽容模式 setenforce permissive

遇到权限问题时, 在log中会打印avc denied提示缺少什么权限, 可以通过dmesg | grep avc过滤出所有avc denied.

解决avc denied

笔者在RK Android9.0上进行操作, 权限文件以.te为后缀, 涉及到需要修改的路径:

android/device/rockchip/common/sepolicy
android/device/rockchip/rk3399/sepolicy

Android自带的进程服务通过以上目录配置即可 , 自己添加的第三方进程需要添加到自定义的目录下

以如下所示的avc denied为例讲解

1
2

# avc: denied { 操作权限 } for pid=7201 comm=“进程名” scontext=u:r:源类型:s0 tcontext=u:r:目标类型:s0 tclass=访问类别 permissive=0
avc: denied { read } for pid=7517 comm="audio@2.0-servi" name="u:object_r:default_prop:s0" dev="tmpfs" ino=11426 scontext=u:r:hal_audio_default:s0 tcontext=u:object_r:default_prop:s0 tclass=file permissive=0

主要关注以下内容:

denied {read}: 表示缺少read权限
scontext=u:r:hal_audio_default:s0: 表示hal_audio_default缺少了权限
tcontext=u:object_r:default_prop:s0: 表示是对default_prop缺少了权限
tclass=file: 表示缺少权限的资源类型为file

因此只要在hal_audio_default.te文件中加入下面内容即可xia

1	allow hal_audio_default tcontext:file read;

如果需要赋予read, open权限, 当有多个权限时用{}包裹

1	allow hal_audio_default tcontext:file { read open };

或者参考android/system/sepolicy/public/global_macros中赋予一个复合权限, 如r_file_perms 表示{ getattr open read ioctl lock map }

待补充

以上内容都是基于Android中自带的进程服务进行配置, 如果是自己引入的进程服务, 则需要自行创建.te文件, 这部分内容后续再来填坑QAQ

Java之JNI开发流程

2019-08-25T08:21:30.000Z

之前介绍过C/C++和Python的相互调用，这一次笔者讲解C/C++和Java的相互调用。Java与C的相互调用需要使用JNI，JNI即Java Native Interface(Java本地接口)。Google提供了NDK(Native Development Kit), NDK包含了一套Android的交叉编译环境和开发库，使用它可以编写C/C++程序后编译成Android环境下使用的动态链接库，Java代码使用JNI规范调用C/C++实现的动态链接库。本文先介绍在命令行下使用JNI，随后介绍在Android Studio中使用JNI。

Java在命令行下使用JNI

笔者以Java中调用C编写的add函数为例讲解，首先创建Hello.java和native.c。在Android Studio下使用JNI中会讲解C与C++在JNI中的不同，并采用C++来讲解JNI。

声明本地方法

在Hello.java中声明一个本地方法，并在静态代码块中加载对应的动态链接库。

public class Hello {

    static {
        // 加载动态链接库    注意：对于libnative.so只需要写native
        System.loadLibrary("native");
    }

    // 声明本地方法
    public static native int addFromC(int a, int b);

    public static void main(String[] argv) {
        // 调用本地方法
        System.out.println("1 + 2 = " + addFromC(1, 2));
    }
}

实现C函数

Java调用C函数需要做C函数和Java本地方法的映射，建立该映射有两种方式: 显式映射和隐式映射。

显式映射

确保Java文件中不指定包名，指定了包名后在命令行下可能会出错，一般步骤如下：

1.包含jni.h头文件

/usr/lib/jvm/java-1.8.0-openjdk-amd64/include

其中jin.h又包含了jni_md.h

/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux

2.实现C函数

3.将C函数加入到映射数组中

4.实现JNI_OnLoad函数

在native.c中实现以上步骤

#include 

#define ARRAY_SIZE(arr)   (sizeof(arr) / sizeof((arr)[0]))

// C函数需要比Java本地方法多出两个参数，这两个参数之后的参数列表与Java本地方法保持一致
// 第一个参数表示JNI环境，该环境封装了所有JNI的操作函数
// 第二个参数为Java代码中调用该C函数的对象
// jint表示JNI的int类型，在本文后面会给出所有JNI类型
jint add(JNIEnv *env, jobject thiz, jint a, jint b)
{
    return a + b;
}

static const JNINativeMethod methods[] = {
    // 第一个参数为Java本地方法名
    // 第二个参数为函数签名：(参数签名)返回值签名， 在本文后面会给出所有签名符号
    // 第三个参数为C函数
    {"addFromC", "(II)I", (void *)add},   // 建立Java本地方法和C函数的映射
};

// 在Java中调用System.loadLibrary方法时会调用到该函数
JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM *jvm, void *reserved)
{
    JNIEnv *env;
    jclass cls;

    // 获取JNI环境
    if ((*jvm)->GetEnv(jvm, (void **)&env, JNI_VERSION_1_8)) {
        return JNI_ERR;
    }

    // 获取Java类
    // JNI_OnLoad函数写法基本固定， 唯一需要修改的是FindClass的第二个参数，即类名
    cls = (*env)->FindClass(env, "Hello");
    if (cls == NULL) {
        return JNI_ERR;
    }

    // 注册本地方法
    if ((*env)->RegisterNatives(env, cls, methods, ARRAY_SIZE(methods)) < 0)
        return JNI_ERR;

    return JNI_VERSION_1_8;
}

编译运行

# 生成动态链接库
gcc -shared -fPIC -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/ -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux/ -o libnative.so native.c 
javac  Hello.java   # 编译Java
java  -Djava.library.path=.   Hello   # 运行Java，并指定动态链接库的路径

隐式映射

在Hello.java的第一行指定包名

1	package cn.caiyifan.jni;

采用隐式映射的方式不需要程序员去手动建立链接，JNI规范已经使用了一套映射规范，在C函数中实现的函数名格式：Java_包名_类名_Java方法名，需要注意的是包名以’_‘隔开，而不是’.‘

#include 

// C函数需要比Java本地方法多出两个参数，这两个参数之后的参数列表与Java本地方法保持一致
// 第一个参数表示JNI环境，该环境封装了所有JNI的操作函数
// 第二个参数为Java代码中调用该C函数的对象
// 函数名格式: Java_包名_类名_Java方法名
jint Java_cn_caiyifan_jni_Hello_addFromC(JNIEnv *env, jobject thiz, jint a, jint b)
{
    return a + b;
}

编译运行

# 生成动态链接库
gcc -shared -fPIC -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/ -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux/ -o libnative.so native.c 
javac -d . Hello.java    # 编译Java并生成完整包名路径
java -Djava.library.path=. cn.caiyifan.jni.Hello   # 运行Java，并指定动态链接库的路径

Android Studio下使用JNI

在Android Studio中使用JNI，借助IDE带来的自动生成功能，就变得很方便。注意笔者使用的Android Studio版本是3.4.2。先讲解JNI中Ｃ与C++的不同后，再在Android Studio下使用C++来进行JNI开发。

JNI中C与C++的不同

从jni.h源码中可以看到JNIEnv的类型是不同的

#if defined(__cplusplus)
typedef _JNIEnv JNIEnv;
#else
typedef const struct JNINativeInterface* JNIEnv;
#endif

由于C++是面向对象的，而C非面向对象，但C如果需要以面向对象方式封装JNI的操作函数，则需要将函数指针封装在结构体内，调用的时候需要传递本结构体的地址，所以在C中调用JNI的方法是下面这样调用的，以NewStringUTF为例

1	(*env)->NewStringUTF(env, "hello world");

通过jni.h源码可知，C++的JNIEnv的作法是包裹C的JNIEnv后，在内部传递this指针进行调用的。所以在C++中直接以对象调用方法的方式调用即可

1	env->NewStringUTF("hello world");

安装JNI开发插件

创建工程

创建Android工程时，选择Native C++。

创建完的工程会比常规的Android工程在src/main下多出一个cpp目录，这是IDE自动生成，编写的C/C++函数放在这个目录下即可。

Java中调用C++

创建一个Jni.java 文件，将Jni的native接口封装成一个单例类。

package cn.caiyifan.jnidemo;

/**
 * 用来封装Jni的native接口
 */
public class Jni {
    static {
        System.loadLibrary("native-lib");
    }

    private static Jni jni;

    private Jni() {}

    public static Jni getInstance() {
        if (jni == null) {
            jni = new Jni();
        }
        return jni;
    }
}

并在Jni类中添加一个getStringFromJni的native方法。

1	public native String getStringFromJni();

这时候Android IDE会报错，提示Cannot resolve corresponding JNI function Java_cn_caiyifan_jnidemo_Jni_getStringFromJni，这个报错是因为没有实现对应的本地函数，只需要按下快捷键Alt+enter，就会在对应的C/C++文件中生成对应的函数接口。

extern "C"
JNIEXPORT jstring JNICALL
Java_cn_caiyifan_jnidemo_Jni_getStringFromJni(JNIEnv *env, jobject instance) {

    // TODO


    return env->NewStringUTF(returnValue);
}

可以看到函数名正是JNI规范要求的格式。修改该函数

extern "C"
JNIEXPORT jstring JNICALL
Java_cn_caiyifan_jnidemo_Jni_getStringFromJni(JNIEnv *env, jobject instance) {
    // env->NewStringUTF 将 char *转换成jstring类型
    return env->NewStringUTF("hello from cpp");
}

然后就可以在MainActivity中调用cpp函数了

package cn.caiyifan.jnidemo;

import androidx.appcompat.app.AppCompatActivity;

import android.os.Bundle;
import android.widget.Toast;

public class MainActivity extends AppCompatActivity {

    @Override
 protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        /**
         * 调用 getStringFromJni native方法
         */
        // 获取Jni对象
        Jni jni = Jni.getInstance();
        // 调用native方法
        String str = jni.getStringFromJni();
        // 显示到Toast上
        Toast.makeText(this, str, Toast.LENGTH_LONG).show();
    }
}

运行到模拟器后，就可以发现成功调用了。

C++中调用Java

在C++中调用Java一般分为四步：

1.获取字节码对象
2.获取jmethodID对象
3.通过字节码对象创建jobject对象
4.通过jobject对象调用方法

其中第3步可视情况省略，当需要调用的Java方法正好位于调用该本地函数的类内，那么JNI函数的第二个参数即表示该对象

在Jni.java中创建一个log_i方法，该方法用来输出log，供C++调用。并且声明一个native方法，在对于的Jni函数中来回调log_i方法。

public void log_i(String tag, String msg) {
    Log.i(tag, msg);
}

public native void callBackFromCpp();

在对应的Cpp函数中回调该log_i方法。对象

extern "C"
JNIEXPORT void JNICALL
Java_cn_caiyifan_jnidemo_Jni_callBackFromCpp(JNIEnv *env, jobject thiz) {
    // 1. 获取字节码对象
    //    参数: 要调用的Java方法所在类的路径
    jclass clazz = env->FindClass("cn/caiyifan/jnidemo/Jni");
    // 2. 获取jmethodID对象
    //    第一个参数: 字节码对象对象对象
    //    第二个参数: Java方法名
    //    第三个参数: Java方法签名     该签名如何编写见文末
    jmethodID methodId = env->GetMethodID(clazz, "log_i", "(Ljava/lang/String;Ljava/lang/String;)V");
    // 3. 通过字节码对象创建jobject对象    此时Jni函数的第二个参数即为jobject对象，所以无需再创建
    // 4. 通过jobject对象调用方法
    //    第一个参数: Jobject对象
    //    第二个参数: jmethodID对象
    //    剩下的可选参数: 调用Java方法所传递的参数
    env->CallVoidMethod(thiz, methodId, env->NewStringUTF("test"), env->NewStringUTF("hello from java"));
}

最后在MainActivity.java中调用该本地方法

1
2
3

// 获取Jni对象
Jni jni = Jni.getInstance(getApplicationContext());
jni.callBackFromCpp();

运行后会发现成功在logcat上进行了打印。

JNI类型与签名

签名的格式为: (参数签名)返回值签名

Java类型	JNI类型	C/C++类型	签名
boolean	jboolean	unsigned char	Z
byte	jbyte	char	B
char	jchar	unsigned short	C
short	jshort	short	S
int	jint	int	I
long	jlong	long long	J
float	jfloat	float	F
double	jdouble	double	V
类	jobject	void *	L用/隔开的全类名;

类: 例如String的签名为Ljava/lang/String; 注意: 包名和类名用/隔开, 结尾有一个;
数组：用[表示数组签名, 例如int[]的签名为[I

javah和javap命令的使用

javah可以生成Java本地方法对应的C/C++函数接口，用法是指定一个class文件，不过在Android Studio中已经可以快捷键生成了。

1	javah cn.caiyifan.jnidemo.Jni

javap -s可以生成一个Java文件所有方法的签名，用法与javah一样

1	javap -s cn.caiyifan.jnidemo.Jni

但在Android Studio中目录结构确定编译后的class目录比较复杂，可以在工程根目录下使用以下命令

1	javap -s `find -name Jni.class`

Linux驱动之PCI子系统剖析

2019-08-09T17:14:52.000Z

PCI是外围设备互连(Peripheral Component Interconnect)的简称，作为一种通用的总线接口标准，它已经普遍使用在了计算机中。PCI总线常见于x86体系，本文默认面向的体系为x86，注意x86架构下IO与内存是独立编址的。

附：本文默认读者熟悉Linux设备驱动模型，不熟悉的可以先阅读这两篇blog。
Linux驱动之I2C子系统剖析
 Linux驱动之SPI子系统剖析

PCI寻址

PCI系统总体布局组织为树状，从CPU连接的Host Bridge引出PCI主桥，主桥连接的是PCI总线0，可以直接连接PCI设备，或者再挂上PCI桥引出下一级PCI总线。

每个PCI设备由一个总线号、设备号和功能号确定。PCI规范允许一个系统最多拥有256条总线，每条总线最多带有32个设备，每个设备可以是最多8个功能的多功能板，但是对于大型系统而言总线数不够，故还支持PCI域，每个PCI域可最多支持256个总线。

PCI域: 16位
总线号: 8位
设备号: 5位
功能号: 3位

在PC机上可以使用lspci查看计算机上PCI设备信息，笔者在自己电脑上执行该命令后输出如下

每一行表示一个PCI设备或者PCI桥，而每行的开头即表示总线号、设备号和功能号。

PCI配置寄存器

所有的PCI设备都有至少256字节的地址空间，其中前64字节是标准化的，被称为PCI配置寄存器，剩下的字节是设备相关的 (取决于具体的厂商，需要查看datasheet得知)。

PCI配置寄存器如下图所示。

Vendor ID: 标识硬件厂商，需要向特定组织进行注册。
Device ID: 由硬件厂商来分配的设备ID，无需对ID进行注册。
Subsystem ID、Subsystem Vendor ID: 用来进一步标识设备。

硬件标识信息在硬件出厂时就写入相应设备中了。

当BIOS启动时，会为每个PCI设备分配内存、IO空间以及irq号，并写入相应PCI设备的配置寄存器中。Linux内核启动时会从PCI设备的配置寄存器里读取内存/IO起始地址以及irq，并把这些信息赋值给struct pci_dev的相应成员来生成软件描述的PCI设备。

从上图的寄存器分布中可以看到中间有一段地址空间描述BARS(Base Address Register)，这些寄存器组用来存储备PCI设备工作时的io地址、irq号和mem地址起始地址以及长度。这些信息存储的具体位置需要查阅相应PCI设备的datasheet方可得知，在内核中提供了以下几个接口来获取这些资源。

/*
 * dev为PCI设备的软件抽象，bar的取值为0 ~ 5
 * 这三个函数分别返回第bar个区域的首地址、尾地址和长度
*/
unsigned long pci_resource_start(struct pci_dev *dev, int bar);
unsigned long pci_resource_end(struct pci_dev *dev, int bar);
unsigned long pci_resource_len(struct pci_dev *dev, int bar);
/*
 * 返回和这个bar相关联资源的标识
 * IORESOURCE_IO：io端口
 * IORESOURCE_MEM：内存
*/
unsigned long pci_resource_flags(struct pci_dev *dev, int bar);

内核提供了一组接口来访问配置空间。

int pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)
int pci_read_config_word(struct pci_dev *dev, int where, u16 *val)
int pci_read_config_dword(struct pci_dev *dev, int where, u32 *val)
int pci_write_config_byte(struct pci_dev *dev, int where, u8 val)
int pci_write_config_word(struct pci_dev *dev, int where, u16 val)
int pci_write_config_dword(struct pci_dev *dev, int where,  u32 val)

PCI驱动的注册及匹配

BIOS在启动时，会为每个PCI设备分配地址和irq等信息，并写入各个PCI设备的配置寄存器中，所以PCI设备无需像其他总线那样去注册设备。

内核中使用struct pci_dev来描述PCI设备的抽象。当linux系统启动时，会探测系统中的所有PCI设备，并为探测到的每个PCI设备做如下操作：
1.分配一个struct pci_dev结构体，用来表示相应的PCI设备
2.为这个结构体填充设备vendor id、device id、subvendor id、subdevice id以及地址和irq信息（通过读取PIC配置寄存器得到）
3.最后把这个struct pci_dev结构体挂接到pci_bus上

内核中使用struct pci_driver来描述PCI驱动的抽象

struct pci_driver {
    struct list_head node;
    char *name;
    const struct pci_device_id *id_table;   /* must be non-NULL for probe to be called */
    int  (*probe)  (struct pci_dev *dev, const struct pci_device_id *id);   /* New device inserted */
    void (*remove) (struct pci_dev *dev);   /* Device removed (NULL if not a hot-plug capable driver) */
    int  (*suspend) (struct pci_dev *dev, pm_message_t state);  /* Device suspended */
    int  (*suspend_late) (struct pci_dev *dev, pm_message_t state);
    int  (*resume_early) (struct pci_dev *dev);
    int  (*resume) (struct pci_dev *dev);                   /* Device woken up */
    void (*shutdown) (struct pci_dev *dev);
    struct pci_error_handlers *err_handler;
    struct device_driver    driver;
    struct pci_dynids dynids;
};

其中id_table用来匹配设备

struct pci_device_id {
    __u32 vendor, device;       /* Vendor and device ID or PCI_ANY_ID*/
    __u32 subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
    __u32 class, class_mask;    /* (class,subclass,prog-if) triplet */
    kernel_ulong_t driver_data; /* Data private to the driver */
};

PCI驱动的注册接口为pci_register_driver(struct pci_driver *drv)，当调用该接口后，会调用PCI总线下的match方法来进行匹配

static int pci_bus_match(struct device *dev, struct device_driver *drv)
{
    struct pci_dev *pci_dev = to_pci_dev(dev);
    struct pci_driver *pci_drv = to_pci_driver(drv);
    const struct pci_device_id *found_id;

    found_id = pci_match_device(pci_drv, pci_dev);
    if (found_id)
        return 1;

    return 0;
}

可以看到pci_bus_match调用的是pci_match_device函数

static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
                            struct pci_dev *dev)
{
    struct pci_dynid *dynid;

    /* Look at the dynamic ids first, before the static ones */
    spin_lock(&drv->dynids.lock);
    list_for_each_entry(dynid, &drv->dynids.list, node) {
        if (pci_match_one_device(&dynid->id, dev)) {
            spin_unlock(&drv->dynids.lock);
            return &dynid->id;
        }
    }
    spin_unlock(&drv->dynids.lock);

    return pci_match_id(drv->id_table, dev);
}

最终调用的是pci_match_id匹配

const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
                     struct pci_dev *dev)
{
    if (ids) {
        while (ids->vendor || ids->subvendor || ids->class_mask) {
            if (pci_match_one_device(ids, dev))
                return ids;
            ids++;
        }
    }
    return NULL;
}

遍历id_table，调用pci_match_one_device进行严格匹配

static inline const struct pci_device_id *
pci_match_one_device(const struct pci_device_id *id, const struct pci_dev *dev)
{
    if ((id->vendor == PCI_ANY_ID || id->vendor == dev->vendor) &&
        (id->device == PCI_ANY_ID || id->device == dev->device) &&
        (id->subvendor == PCI_ANY_ID || id->subvendor == dev->subsystem_vendor) &&
        (id->subdevice == PCI_ANY_ID || id->subdevice == dev->subsystem_device) &&
        !((id->class ^ dev->class) & id->class_mask))
        return id;
    return NULL;
}

分别对vendor、device、subvendor、subdevice和class进行匹配，除非某一项配置为PCI_ANY_ID，否则都要进行严格匹配，只要有一项匹配不上则直接匹配失败。

Linux驱动之SPI子系统剖析

2019-07-22T16:22:40.000Z

SPI硬件基本概念

SPI总线由四根通信线组成，全双工、主从方式串行同步通信，一次传输8bit，高位在前，低位在后。

MOSI(Master Out Slave In): 主设备输出从设备输入
MISO(Master In Slave out): 从设备输入主设备输出
SCLK：同步信号的时钟线
CS: 片选线，通过片选来选择与哪一个从设备通信
注: 与I2C对比，由于SPI采用的是两根单向的数据线，而不是I2C采用的双向数据线，所以SPI为全双工通信，而I2C半双工。
I2C选择总线上挂接的一个从设备是使用从地址来区分的，而SPI采用的是CS片选线

SPI子系统框架

SPI核心层： drivers/spi/spi.c
SPI总线驱动层(主机控制器驱动层)：drivers/spi/spi_s3c24xx. c
SPI设备驱动层：drivers/spi/spidev.c (内核提供的SPI通用设备驱动)

Linux中的主从模式的总线子系统采用的是同一种分离思想，其分离的具体策略大同小异，同样分为设备驱动层、核心层、总线驱动层。具体的分离策略详细分析可参考Linux驱动之I2C子系统剖析中内核对I2C子系统框架的阐述。笔者在这与I2C子系统类比，列出数据结构名。

	I2C	SPI
主机适配器(控制器)	struct i2c_adapter	struct spi_master
机控制器的操作方法	struct i2c_algorithm	struct spi_bitbang
从机设备	struct i2c_client	struct spi_device
从机设备板卡信息	struct i2c_board_info	struct spi_board_info
从机设备驱动	struct i2c_driver	struct spi_driver
一次完整的数据包	struct i2c_msg	struct spi_transfer
多个完整数据包的封装	无	struct spi_message

源码分析

由于子系统架构与I2C等总线类似，所以不会在一些重复部分展开，具体分析可以参考的Linux驱动之I2C子系统剖析中的分析方法。

SPI核心层

SPI核心层代码位于drivers/spi/spi.c 中, 从init函数开始分析

static int __init spi_init(void)
{
    int status;

    buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
    if (!buf) {
        status = -ENOMEM;
        goto err0;
    }

    status = bus_register(&spi_bus_type);     /* 注册SPI总线 */
    if (status < 0)
        goto err1;

    status = class_register(&spi_master_class);     /* 注册SPI类 */
    if (status < 0)
        goto err2;
    return 0;

err2:
    bus_unregister(&spi_bus_type);
err1:
    kfree(buf);
    buf = NULL;
err0:
    return status;
}

spi_init函数如同I2C核心层中的init函数一样做了两件事，注册SPI总线和创建SPI类，这是内核驱动模型的基本套路，就不比多说了。接下来看下match函数

static const struct spi_device_id *spi_match_id(const struct spi_device_id *id,
                        const struct spi_device *sdev)
{
    while (id->name[0]) {
        if (!strcmp(sdev->modalias, id->name))
            return id;
        id++;
    }
    return NULL;
}

/* SPI总线的match方法 */
static int spi_match_device(struct device *dev, struct device_driver *drv)
{
    const struct spi_device *spi = to_spi_device(dev);
    const struct spi_driver *sdrv = to_spi_driver(drv);

    if (sdrv->id_table)
        return !!spi_match_id(sdrv->id_table, spi);

    return strcmp(spi->modalias, drv->name) == 0;
}

可以看到，SPI设备和驱动的匹配是先匹配id_table中的name和设备的modalias，然后匹配驱动的name和设备的modalias。

SPI总线驱动层

SPI的控制器驱动，即总线驱动层位于drivers/spi/spi_s3c24xx. c中，从init函数开始分析。

static int __init s3c24xx_spi_init(void)
{   
    return platform_driver_probe(&s3c24xx_spi_driver, s3c24xx_spi_probe);
}

会发现SPI控制器驱动并不是用的是platform_driver_register接口来注册的，而是使用了另一个接口platform_driver_probe, 其实这是内核提供的不支持热插拔方式的专用平台总线驱动的注册接口，该接口接受两个参数，第一个就是熟知的struct platform_driver，第二个则是probe函数，当驱动和设备匹配上后就会调用这个probe函数。进入到 s3c24xx_spi_probe函数进行分析，probe函数的代码比较多，分段进行分析。

struct s3c2410_spi_info *pdata;
struct s3c24xx_spi *hw;
struct spi_master *master;
struct resource *res;
int err = 0;

/* 实例化spi控制器 */
master = spi_alloc_master(&pdev->dev, squdongqudongizeof(struct s3c24xx_spi));
if (master == NULL) {
    dev_err(&pdev->dev, "No memory for spi_master\n");
    err = -ENOMEM;
    goto err_nomem;
}

/* 获取spi的私有数据结构体并初始化为空 */
hw = spi_master_get_devdata(master);
memset(hw, 0, sizeof(struct s3c24xx_spi));

/* 设置spi的私有数据*/
hw->master = spi_master_get(master);
hw->pdata = pdata = pdev->dev.platform_data;
hw->dev = &pdev->dev;

if (pdata == NULL) {
    dev_err(&pdev->dev, "No platform data supplied\n");
    err = -ENOENT;
    goto err_no_pdata;
}

platform_set_drvdata(pdev, hw);
init_completion(&hw->done);     /* 初始化completion,  用于IO的同步*/

实例化SPI控制器后设置SPI的私有数据，然后初始化completion。

/* initialise fiq handler */

s3c24xx_spi_initfiq(hw);       /* 初始化s3c24xx_spi结构体中的handler，为其绑定中断处理函数 */

/* setup the master state. */

/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;

master->num_chipselect = hw->pdata->num_cs;
master->bus_num = pdata->bus_num;

这一段初始化s3c24xx_spi结构体中的handler，为其绑定中断处理函数，然后设置了主机控制器支持的SPI模式，设置master的片选线编号和总线编号。

hw->bitbang.master         = hw->master;
hw->bitbang.setup_transfer = s3c24xx_spi_setupxfer;
hw->bitbang.chipselect     = s3c24xx_spi_chipsel;
hw->bitbang.txrx_bufs      = s3c24xx_spi_txrx;

hw->master->setup  = s3c24xx_spi_setup;
hw->master->cleanup = s3c24xx_spi_cleanup;

bitbang表示的是SPI的操作方法，这一段关键是填充了setup_transfer，即传输方法。

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
    dev_err(&pdev->dev, "Cannot get IORESOURCE_MEM\n");
    err = -ENOENT;
    goto err_no_iores;
}

hw->ioarea = request_mem_region(res->start, resource_size(res),
                pdev->name);

if (hw->ioarea == NULL) {
    dev_err(&pdev->dev, "Cannot reserve region\n");
    err = -ENXIO;
    goto err_no_iores;
}

hw->regs = ioremap(res->start, resource_size(res));
if (hw->regs == NULL) {
    dev_err(&pdev->dev, "Cannot map IO\n");
    err = -ENXIO;
    goto err_no_iomap;
}

hw->irq = platform_get_irq(pdev, 0);
if (hw->irq < 0) {
    dev_err(&pdev->dev, "No IRQ specified\n");
    err = -ENOENT;
    goto err_no_irq;
}

err = request_irq(hw->irq, s3c24xx_spi_irq, 0, pdev->name, hw);
if (err) {
    dev_err(&pdev->dev, "Cannot claim IRQ\n");
    goto err_no_irq;
}

hw->clk = clk_get(&pdev->dev, "spi");
if (IS_ERR(hw->clk)) {
    dev_err(&pdev->dev, "No clock for device\n");
    err = PTR_ERR(hw->clk);
    goto err_no_clk;
}

/* setup any gpio we can */

if (!pdata->set_cs) {
    if (pdata->pin_cs < 0) {
        dev_err(&pdev->dev, "No chipselect pin\n");
        goto err_register;
    }

    err = gpio_request(pdata->pin_cs, dev_name(&pdev->dev));
    if (err) {
        dev_err(&pdev->dev, "Failed to get gpio for cs\n");
        goto err_register;
    }

    hw->set_cs = s3c24xx_spi_gpiocs;
    gpio_direction_output(pdata->pin_cs, 1);
} else
    hw->set_cs = pdata->set_cs;

s3c24xx_spi_initialsetup(hw);  
    s3c24xx_spi_initialsetup(hw);  /* spi 控制器初始化 */

/* register our spi controller */

/* 内部最后spi_register_master来注册SPI控制器 */
err = spi_bitbang_start(&hw->bitbang);
if (err) {
    dev_err(&pdev->dev, "Failed to register SPI master\n");
    goto err_register;weiyu
}

这一段是跟具体硬件息息相关的，从获取平台资源开始，然后分别做了IO的映射、中断的申请与中断处理函数的绑定、时钟的初始化和片选的GPIO的申请和拉高电平。最后关键是调用了s3c24xx_spi_initialsetup函数，该函数内部最后调用了spi_register_master方法来注册SPI控制器。类比I2C在probe函数中调用的i2c_add_numbered_adapter函数，其内部会扫描SPI的板卡信息，然后利用板卡信息生成SPI设备，并将控制器spi_master挂接到spi_device上，随后在SPI设备驱动层中注册设备驱动后调用probe函数会获取到该spi_device，然后即可通过spi_device 中挂接的spi_master来调用控制器的操作方法spi_bitbang_transfer来传输数据。要注意的是SPI与I2C提供的通用设备驱动不同，其设备节点的生成并不是在注册主机控制器中完成的，而是在通用设备中完成的，这一段从之后设备驱动层的分析可以看出。这一段逻辑类似于I2C，就不参考源码分析了。(好吧，一如既往的懒QAQ)

SPI设备驱动层

SPI通用设备驱动位于drivers/spi/spidev.c中，从init函数开始。

static struct spi_driver spidev_spi_driver = {
    .driver = {
        .name =     "spidev",
        .owner =    THIS_MODULE,
    },
    .probe =    spidev_probe,
    .remove =   __devexit_p(spidev_remove),
};

static int __init spidev_init(void)
{
    int status;

    /* Claim our 256 reserved device numbers.  Then register a class
     * that will key udev/mdev to add/remove /dev nodes.  Last, register
     * the driver which manages those device numbers.
     */
    BUILD_BUG_ON(N_SPI_MINORS > 256);
    /* 注册为字符设备驱动，为应用层提供调用接口 */
    status = register_chrdev(SPIDEV_MAJOR, "spi", &spidev_fops);
    if (status < 0)
        return status;

    /* 创建spidev类 */
    spidev_class = class_create(THIS_MODULE, "spidev");
    if (IS_ERR(spidev_class)) {
        unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);
        return PTR_ERR(spidev_class);
    }

    /* 调用核心层提供的接口来注册设备驱动 */
    status = spi_register_driver(&spidev_spi_driver);
    if (status < 0) {
        class_destroy(spidev_class);
        unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);
    }
    return status;
}

有空再写了，先休息啦

Linux驱动之Misc子系统剖析

2019-07-03T10:21:40.000Z

何为Misc设备

Linux驱动分为字符设备驱动、块设备驱动和网络设备驱动，而字符设备又包括很多种，内核使用主设备号来区分各个字符设备驱动，在include/linux/major.h文件中已经预先定义好了各类字符设备的主设备号，但是即便如此，仍然存在着大量字符设备无法准确归类，对于这些设备，内核提供了一种Misc（杂项）设备来安放它们的去处。

使用Misc设备的好处

Misc子系统使用一个统一的主设备号来管理，当需要注册Misc驱动时，内核会为其分配次设备号。而如果采用普通字符设备驱动的方式，无论主设备号是静态分配还是动态分配，都会消耗掉一个主设备号，而且如果系统存在着大量的无法准确归类的字符设备驱动，那会大量浪费主设备号;当需要开发一个功能较简单的字符设备驱动，导出接口让用户空间程序方便地控制硬件，只需要使用Misc框架提供的接口即可快速地实现一个Misc设备驱动。

源码分析

Misc框架位于driver/char/misc.c文件中，从misc_init函数开始分析

static int __init misc_init(void)
{
    int err;

#ifdef CONFIG_PROC_FS
    proc_create("misc", 0, NULL, &misc_proc_fops);
#endif
    misc_class = class_create(THIS_MODULE, "misc");      // 创建misc类
    err = PTR_ERR(misc_class);
    if (IS_ERR(misc_class))
        goto fail_remove;

    err = -EIO;
    if (register_chrdev(MISC_MAJOR,"misc",&misc_fops))  // misc通过实现为字符设备驱动来注册
        goto fail_printk;
    misc_class->devnode = misc_devnode;
    return 0;

fail_printk:
    printk("unable to get major %d for misc devices\n", MISC_MAJOR);
    class_destroy(misc_class);
fail_remove:
    remove_proc_entry("misc", NULL);
    return err;
}

先是创建了Misc类，随后将Misc子系统实现为字符设备驱动来注册到内核中，并为其绑定了fops。

static const struct file_operations misc_fops = {
    .owner      = THIS_MODULE,
    .open       = misc_open,
};

fops只实现了open方法，暂且不分析fops，先分析内核为驱动开发人员导出的注册接口misc_register

int misc_register(struct miscdevice * misc)
{
    struct miscdevice *c;
    dev_t dev;
    int err = 0;

    INIT_LIST_HEAD(&misc->list);

    mutex_lock(&misc_mtx);
    // 查找设备是否已经注册 
    list_for_each_entry(c, &misc_list, list) {
        if (c->minor == misc->minor) {
            mutex_unlock(&misc_mtx);
            return -EBUSY;
        }
    }

    // 动态分配次设备号
    if (misc->minor == MISC_DYNAMIC_MINOR) {
        int i = find_first_zero_bit(misc_minors, DYNAMIC_MINORS);   // 找到位图中第一个为0的bit
        if (i >= DYNAMIC_MINORS) {       // 没有找到
            mutex_unlock(&misc_mtx);
            return -EBUSY;
        }
        misc->minor = DYNAMIC_MINORS - i - 1;   // 分配次设备号
        set_bit(i, misc_minors);                // 将分配的次设备号加入位图
    }

    // 生成设备号
    dev = MKDEV(MISC_MAJOR, misc->minor);

    // 注册设备
    misc->this_device = device_create(misc_class, misc->parent, dev,
                      misc, "%s", misc->name);
    if (IS_ERR(misc->this_device)) {
        int i = DYNAMIC_MINORS - misc->minor - 1;
        if (i < DYNAMIC_MINORS && i >= 0)
            clear_bit(i, misc_minors);
        err = PTR_ERR(misc->this_device);
        goto out;
    }

    /*
     * Add it to the front, so that later devices can "override"
     * earlier defaults
     */ 
    // 将已注册的驱动添加到链表上，open时可遍历链表来替换真正的fops
    list_add(&misc->list, &misc_list);
 out:
    mutex_unlock(&misc_mtx);
    return err;
}

从上面可以看到，先查找设备是否已经注册（内核采用一个链表来管理已经注册的Misc设备驱动），然后判断是否需要动态分配次设备号（内核使用位图来管理已经注册的Misc次设备号），然后生成设备号，通过device_create函数在Misc类下创建设备，这时候/dev目录下就会根据misc->name的值生成设备节点，然后将已经注册的驱动添加到链表上。

把关注点放到该接口需要传递的结构体struct miscdevice

struct miscdevice  {
    int minor;
    const char *name;
    const struct file_operations *fops;   // 真正的fops
    struct list_head list;
    struct device *parent;
    struct device *this_device;
    const char *nodename;
    mode_t mode;
};

可以看到该结构体内部也定义了一个fops，需要驱动开发者使用该接口时实现一个fops，其实这个才是真正的fops，而在misc_init函数中调用register_chrdev来绑定的fops是用来中转数据的，具体情况可以从其open方法可以分析出来。

static int misc_open(struct inode * inode, struct file * file)
{
    int minor = iminor(inode);
    struct miscdevice *c;
    int err = -ENODEV;
    const struct file_operations *old_fops, *new_fops = NULL;

    mutex_lock(&misc_mtx);

    // 遍历链表来查找真正的fops
    list_for_each_entry(c, &misc_list, list) {
        if (c->minor == minor) {
            new_fops = fops_get(c->fops);   // 获取真正的fops
            break;
        }
    }
        
    if (!new_fops) {
        mutex_unlock(&misc_mtx);
        request_module("char-major-%d-%d", MISC_MAJOR, minor);
        mutex_lock(&misc_mtx);

        list_for_each_entry(c, &misc_list, list) {
            if (c->minor == minor) {
                new_fops = fops_get(c->fops);
                break;
            }
        }
        if (!new_fops)
            goto fail;
    }

    err = 0;
    old_fops = file->f_op;
    // 替换真正的fops，之后再调用其他接口（write、ioctl、close）时调用的是真正的fops
    file->f_op = new_fops;
    // 调用真正的fops中的open方法
    if (file->f_op->open) {
        file->private_data = c;
        err=file->f_op->open(inode,file);
        if (err) {
            fops_put(file->f_op);
            file->f_op = fops_get(old_fops);
        }
    }
    fops_put(old_fops);
fail:
    mutex_unlock(&misc_mtx);
    return err;
}

遍历用来管理Misc设备驱动的链表，根据次设备号来找到真正的由驱动开发者用misc_register接口注册的Misc驱动，然后获取其fops，该fops就是真正的fops。然后替换真正的fops，之后再调用其他接口（write、ioctl、close）时调用的则是真正的fops，所以用来中转数据的那个fops只定义了一个open方法。最后，该open方法并不是真正的open方法，所以需要调用真正的fops中的open方法。

总结

Misc子系统使用同一个驱动来向上提供多个设备文件节点，向下控制多个(相应的)设备。Misc驱动本质上也是字符驱动，只是它借用Misc子系统的框架来更方便的向内核注册而已。驱动开发人员只需要把Misc设备的一些基本信息通过struct miscdevice来构建，再通过misc_register接口向内核注册即可。

Linux驱动之I2C子系统剖析

2019-06-30T04:38:38.000Z

I2C是广泛应用于计算机中的串行总线，用于处理器和其外设之间的通信。

I2C硬件基本概念

I2C总线由两根传递数据的双向信号线与一根地线组成，半双工、主从方式通信。
- Serial Clock Line (SCL)
- Serial Data Address (SDA)
每个设备都有一个唯一设备地址，一次传输8bit，高位在前，低位在后。
一次完整的I2C通信需要经历一个完整的时序，I2C总线通信完整时序如下图。一般在驱动中无需关心具体时序，只需操作SoC中的I2C控制器即可，只有在裸机下需要用GPIO模拟I2C通信时才需用到，所以笔者在本文不阐述I2C时序（其实就是懒 O__O “…）。
总线速度有三种模式
- 标准模式 100kbps
- 快速模式 400kbps
- 高速模式 3.4Mbps

I2C子系统框架

I2C设备驱动层：drivers/i2c/i2c-dev.c (通用型) 或者为特定设备定制的设备驱动（比如E2PROM驱动）
I2C核心层： drivers/i2c/i2c-coere.c
I2C总线驱动层(主机控制器驱动层)：drivers/i2c/busses/i2c-s3c2410.c

I2C设备驱动层

是I2C从机的驱动程序
给用户提供调用接口
内核提供两种方式来实现设备驱动：
- 第一种是内核默认实现的通用型的I2C设备驱动，位于drivers/i2c/i2c-dev.c中。这种方式仅仅只是封装了I2C的基本操作，相当于只是封装了I2C的基本时序，向应用层只提供了I2C基本操作的接口，该接口通用于所有的I2C设备。具体设备相关的操作，需要开发者在应用层根据硬件特性来完成对设备的操作。该方式的优点就是通用，而缺点也很明显，封装的不够彻底，需要应用开发人员对硬件有一定程度的了解。
- 第二种是根据特定设备来编写的特定的I2C设备驱动, 该方式彻底封装了硬件的操作，提供给应用层的接口彻底屏蔽I2C的通信细节。该方式的优点就是应用开发人员无需关心硬件。

I2C核心层

注册I2C总线
由内核开发人员编写的，不涉及具体硬件
给驱动编程人员提供编程接口

I2C总线驱动层

是I2C主机适配器的驱动程序
初始化I2C适配器(控制器)
实现操作方法：根据I2C操作时序进行操作I2C控制器实现收发数据

源码分析

源码中会涉及到一部分SMBus相关内容，SMBus是Intel在I2C的基础上开发的类似I2C的总线，本文不探讨SMBus相关内容（其实说白了，还是懒QAQ）。笔者会大体上对I2C子系统的源码进行分析，如若分析的有出入，还望指出。

I2C核心层

I2C核心层的实现位于drivers/i2c/i2c-core.c中，笔者从i2c_init函数开始分析。

static int __init i2c_init(void)
{
    int retval;

    retval = bus_register(&i2c_bus_type);     // 注册I2C总线 
    if (retval)
        return retval;
#ifdef CONFIG_I2C_COMPAT
    i2c_adapter_compat_class = class_compat_register("i2c-adapter");
    if (!i2c_adapter_compat_class) {
        retval = -ENOMEM;
        goto bus_err;
    }
#endif
    retval = i2c_add_driver(&dummy_driver);    // 注册了一个虚假的I2C驱动
    if (retval)
        goto class_err;
    return 0;

class_err:
#ifdef CONFIG_I2C_COMPAT
    class_compat_unregister(i2c_adapter_compat_class);
bus_err:
#endif
    bus_unregister(&i2c_bus_type);
    return retval;
}

该函数先是调用了bus_register函数注册了I2C总线，随后调用i2c_add_driver函数来注册了一个虚假的I2C驱动。

先对注册的I2C总线i2c_bus_type进行分析

struct bus_type i2c_bus_type = {
    .name       = "i2c",
    .match      = i2c_device_match,
    .probe      = i2c_device_probe,
    .remove     = i2c_device_remove,
    .shutdown   = i2c_device_shutdown,
    .pm     = &i2c_device_pm_ops,
};

根据Linux设备驱动模型的原理，I2C总线下会挂载两条链表，分别为设备链和驱动链，只要其中一个链表有结点插入，即会通过i2c_device_match函数来遍历另一条链表去匹配设备与驱动，一旦匹配上则会调用i2c_device_probe函数，而i2c_device_probe函数又会调用i2c_driver的probe函数。进到i2c_device_match和i2c_device_probe进行分析。

static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
    struct i2c_client   *client = i2c_verify_client(dev);
    struct i2c_driver   *driver;

    if (!client)
        return 0;

    driver = to_i2c_driver(drv);
    /* match on an id table if there is one */
    if (driver->id_table)
        return i2c_match_id(driver->id_table, client) != NULL;

    return 0;
}

可以看到, i2c_device_match函数调用的是i2c_match_id函数来进行匹配。从源码中可见，需要注意的是I2C总线匹配方式不同于Platform总线，I2C总线只匹配id_table中的name，并不会去匹配driver中的name。

static int i2c_device_probe(struct device *dev)
{
    struct i2c_client  *client = i2c_verify_client(dev);
    struct i2c_driver  *driver;
    int status;

    if (!client)
        return 0;

    driver = to_i2c_driver(dev->driver);
    if (!driver->probe || !driver->id_table)
        return -ENODEV;
    client->driver = driver;
    if (!device_can_wakeup(&client->dev))
        device_init_wakeup(&client->dev,
                    client->flags & I2C_CLIENT_WAKE);
    dev_dbg(dev, "probe\n");

    /* 调用driver中的probe函数 */
    status = driver->probe(client, i2c_match_id(driver->id_table, client));
    if (status) {
        client->driver = NULL;
        i2c_set_clientdata(client, NULL);
    }
    return status;
}

可以看到，的确是调用driver->probe来进行真正的probe。需要注意的是if (!driver->probe || !driver->id_table) return -ENODEV;中对id_table进行了非空判断，所以如果采用设备树方式进行匹配也需要对.id_table进行有效赋值，否则会出现match上了但probe函数不会调用的奇怪现象，个人感觉这应该是个bug，毕竟这个核心层在设备树出现之前就已经存在了。

回到i2c_init函数，然后注册了一个空的名为dummy的i2c_driver。

static int dummy_probe(struct i2c_client *client,
               const struct i2c_device_id *id)
{
    return 0;
}

static int dummy_remove(struct i2c_client *client)
{
    return 0;
}

static struct i2c_driver dummy_driver = {
    .driver.name    = "dummy",
    .probe      = dummy_probe,
    .remove     = dummy_remove,
    .id_table   = dummy_id,
};

可以看到这是一个完全空的虚假驱动，而I2C核心层为何要注册一个假的驱动不得而知，笔者查阅了网上资料也没法得知，但是/sys/bus/i2c/drivers/dummy确实存在，所以笔者猜测应该纯粹是开发该层次调试用的。

核心层还提供了一系列函数接口供驱动开发者注册和注销驱动：

i2c_add_adapter 注册I2C主机适配器驱动 (动态分配总线号)
i2c_add_numbered_adapter 注册I2C主机适配器驱动 (静态指定总线号)
i2c_del_adapter 注销I2C主机适配器驱动
i2c_add_driver 注册I2C从机设备驱动
i2c_del_driver 注销I2C从机设备驱动

其他函数暂不分析，在分析其他层的时候调用时再进行分析。

I2C设备驱动层

笔者先从内核提供的通用驱动开始分析，最后在文末给出特定驱动的分析。内核提供了一个通用于所有设备的I2C设备驱动，用户可以在应用层实现对I2C的驱动，其实现位于drivers/i2c/i2c-dev.c中。同样从init函数开始，笔者从i2c_dev_init函数开始分析。

static int __init i2c_dev_init(void)
{
    int res;

    printk(KERN_INFO "i2c /dev entries driver\n");

    /* 将通用驱动注册为字符设备驱动，并提供file_operations 操作方法 */
    res = register_chrdev(I2C_MAJOR, "i2c", &i2cdev_fops);
    if (res)
        goto out;

    /* 创建类 */
    i2c_dev_class = class_create(THIS_MODULE, "i2c-dev");
    if (IS_ERR(i2c_dev_class)) {
        res = PTR_ERR(i2c_dev_class);
        goto out_unreg_chrdev;
    }

    /* 注册I2C从机设备驱动 */
    res = i2c_add_driver(&i2cdev_driver);
    if (res)
        goto out_unreg_class;

    return 0;

out_unreg_class:
    class_destroy(i2c_dev_class);
out_unreg_chrdev:
    unregister_chrdev(I2C_MAJOR, "i2c");
out:
    printk(KERN_ERR "%s: Driver Initialisation failed\n", __FILE__);
    return res;
}

i2c_dev_init函数先是调用了register_chrdev函数注册了一个字符设备驱动，并提供了一个file_operations。由此可见，是将通用驱动实现为字符设备驱动，并由其file_operations结构体的方法为应用层提供通用接口。然后调用class_create创建了一个类，但是可以看到并没有调用device_create在该类下创建设备，所以注意在这里并没有生成设备节点。最后调用i2c_add_driver注册了一个I2C从机设备驱动i2cdev_driver。i2cdev_driver定义如下。

static struct i2c_driver i2cdev_driver = {
    .driver = {
        .name   = "dev_driver",
    },
    .attach_adapter = i2cdev_attach_adapter,
    .detach_adapter = i2cdev_detach_adapter,
};

从上可以看到并没有对id_table进行赋值，从上文在I2C核心层分析可知，I2C总线是根据id_table进行匹配，所以这里并不会按照常规的Linux驱动模型进行match后probe，况且这个驱动里也没有probe方法。所以这到底是什么情况？别慌，虽然没有id_table和probe，但是它单独提供了两个方法attach_adapter和detach_adapter。这里先埋个伏笔，不做分析，到I2C总线驱动层分析后自然会柳暗花明。

I2C总线驱动层

笔者使用的SoC是S5PV210，其控制器跟S3C2410基本一致，所以三星的驱动开发者并没有再去写一份S5PV210的主机适配器驱动，而是使用了S3C2410的主机适配器驱动，其位于drivers/i2c/busses/i2c-s3c2410.c中。

从i2c_adap_s3c_init函数开始分析。

static int __init i2c_adap_s3c_init(void)
{
    return platform_driver_register(&s3c24xx_i2c_driver);
}

可以看到其作为平台设备驱动而实现，注册了s3c24xx_i2c_driver驱动。

static struct platform_device_id s3c24xx_driver_ids[] = {
    {
        .name       = "s3c2410-i2c",
        .driver_data    = TYPE_S3C2410,
    }, {
        .name       = "s3c2440-i2c",
        .driver_data    = TYPE_S3C2440,
    }, { },
};
MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);

static struct platform_driver s3c24xx_i2c_driver = {
    .probe      = s3c24xx_i2c_probe,
    .remove     = s3c24xx_i2c_remove,
    .id_table   = s3c24xx_driver_ids,
    .driver     = {
        .owner  = THIS_MODULE,
        .name   = "s3c-i2c",
        .pm = S3C24XX_DEV_PM_OPS,
    },
};

根据平台总线的原理，很容易得知在arch/arm/mach-s5pv210/mach-x210.c中对其驱动对应的设备进行了注册，其注册的设备定义位于dev-i2c0.c，这是I2C的资源文件。其定义的资源如下。

static struct resource s3c_i2c_resource[] = {
    [0] = {
        .start = S3C_PA_IIC,
        .end   = S3C_PA_IIC + SZ_4K - 1,
        .flags = IORESOURCE_MEM,
    },
    [1] = {
        .start = IRQ_IIC,
        .end   = IRQ_IIC,
        .flags = IORESOURCE_IRQ,
    },
};

struct platform_device s3c_device_i2c0 = {
    .name         = "s3c2410-i2c",
    .id       = 0,
    .num_resources    = ARRAY_SIZE(s3c_i2c_resource),
    .resource     = s3c_i2c_resource,
};

由name可知，与s3c24xx_i2c_driver是匹配的。除此之外，还定义了平台数据default_i2c_data0和default_i2c_data0函数。其相关的调用还是在arch/arm/mach-s5pv210/mach-x210.c中进行的，在mach-x210.c中的smdkc110_machine_init函数中进行了如下调用

/* i2c */
// 设置I2C平台数据       NULL表示设置默认的平台数据
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_i2c2_set_platdata(NULL);

现在进到s3c_i2c0_set_platdata函数进行分析。

static struct s3c2410_platform_i2c default_i2c_data0 __initdata = {
    .flags      = 0,
    .slave_addr = 0x10,          // I2C控制器作为从设备时使用的地址
    .frequency  = 400*1000,      // 400kbps
    .sda_delay  = S3C2410_IICLC_SDA_DELAY15 | S3C2410_IICLC_FILTER_ON,   // 间隔时间
};

void __init s3c_i2c0_set_platdata(struct s3c2410_platform_i2c *pd)
{
    struct s3c2410_platform_i2c *npd;

    if (!pd)   // 参数为NULL则使用该函数上面定义的默认的平台数据
        pd = &default_i2c_data0;

    npd = kmemdup(pd, sizeof(struct s3c2410_platform_i2c), GFP_KERNEL);
    if (!npd)
        printk(KERN_ERR "%s: no memory for platform data\n", __func__);
    else if (!npd->cfg_gpio)
        npd->cfg_gpio = s3c_i2c0_cfg_gpio;  // GPIO初始化方法

    // 设置为平台数据
    s3c_device_i2c0.dev.platform_data = npd;
}

可以看到传递NULL则使用了默认的平台数据, 将s3c_i2c0_cfg_gpio函数设置到了平台数据cfg_gpio方法中，最后将平台数据挂接到s3c_device_i2c0这个设备上。

void s3c_i2c0_cfg_gpio(struct platform_device *dev)
{
    s3c_gpio_cfgpin(S5PV210_GPD1(0), S3C_GPIO_SFN(2));      // 设置控制寄存器为I2C0_SDA模式
    s3c_gpio_setpull(S5PV210_GPD1(0), S3C_GPIO_PULL_NONE);     
    s3c_gpio_cfgpin(S5PV210_GPD1(1), S3C_GPIO_SFN(2));      // 设置控制寄存器为I2C0_SCL模式
    s3c_gpio_setpull(S5PV210_GPD1(1), S3C_GPIO_PULL_NONE);  
}

可以看到s3c_i2c0_cfg_gpio函数只是对I2C控制器两根通信线的GPIO初始化。

接下去回到I2C总线驱动层i2c-s3c2410.c中, 进入到s3c24xx_i2c_probe函数进行分析。 probe函数的代码比较多，分段进行分析。

struct s3c24xx_i2c *i2c;
struct s3c2410_platform_i2c *pdata;
struct resource *res;
int ret;

// 获取I2C平台数据
pdata = pdev->dev.platform_data;
if (!pdata) {
    dev_err(&pdev->dev, "no platform data\n");
    return -EINVAL;
}

i2c = kzalloc(sizeof(struct s3c24xx_i2c), GFP_KERNEL);
if (!i2c) {
    dev_err(&pdev->dev, "no memory for state\n");
    return -ENOMEM;
}

strlcpy(i2c->adap.name, "s3c2410-i2c", sizeof(i2c->adap.name));
i2c->adap.owner   = THIS_MODULE;
i2c->adap.algo    = &s3c24xx_i2c_algorithm;      // I2C主机控制器的操作方法
i2c->adap.retries = 2;
i2c->adap.class   = I2C_CLASS_HWMON | I2C_CLASS_SPD;
i2c->tx_setup     = 50;

三星采用struct s3c24xx_i2c结构体来对SoC的控制器进行抽象，该结构体继承于struct i2c_adapter。该段代码先是从device中获取了平台数据，该平台数据即是上文调用s3c_i2c0_set_platdata函数时设置的。然后对i2c->adap进行了相关赋值，关键部分是i2c->adap.algo = &s3c24xx_i2c_algorithm; ，adap.algo表示I2C主机控制器的操作方法，将该SoC的操作方法挂接到了适配器上。s3c24xx_i2c_algorithm定义了两个操作方法，主要是master_xfer方法，用来发送消息。代码如下。

static const struct i2c_algorithm s3c24xx_i2c_algorithm = {
    .master_xfer        = s3c24xx_i2c_xfer,
    .functionality      = s3c24xx_i2c_func,
};

s3c24xx_i2c_xfer涉及到对具体控制器的操作，不进行展开，但是注意的是其内部调用的是s3c24xx_i2c_doxfer，在s3c24xx_i2c_doxfer函数内部发送完数据后，调用wait_event_timeout函数来进行睡眠等待从机响应。因此可知内核中I2C的等待从机的ACK信号是通过中断实现的，即主机发送完数据后进入睡眠等待从机，从机响应后通过中断通知主机后唤醒。

probe函数接着做了获取时钟和使能时钟，相关代码如下。

// 获取时钟
    i2c->clk = clk_get(&pdev->dev, "i2c");

    if (IS_ERR(i2c->clk)) {
        dev_err(&pdev->dev, "cannot get clock\n");
        ret = -ENOENT;
        goto err_noclk;
    }

    dev_dbg(&pdev->dev, "clock source %p\n", i2c->clk);

    // 使能时钟
    clk_enable(i2c->clk);

紧接着对具体IO和IRQ进行操作。

// 获取I2C平台资源（IO内存地址、IRQ）
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
    dev_err(&pdev->dev, "cannot find IO resource\n");
    ret = -ENOENT;
    goto err_clk;
}

i2c->ioarea = request_mem_region(res->start, resource_size(res),
                 pdev->name);

if (i2c->ioarea == NULL) {
    dev_err(&pdev->dev, "cannot request IO\n");
    ret = -ENXIO;
    goto err_clk;
}

// 将物理地址映射为虚拟地址
i2c->regs = ioremap(res->start, resource_size(res));

if (i2c->regs == NULL) {
    dev_err(&pdev->dev, "cannot map IO\n");
    ret = -ENXIO;
    goto err_ioarea;
}

dev_dbg(&pdev->dev, "registers %p (%p, %p)\n",
    i2c->regs, i2c->ioarea, res);

/* setup info block for the i2c core */

i2c->adap.algo_data = i2c;
i2c->adap.dev.parent = &pdev->dev;

/* initialise the i2c controller */

// 初始化I2C控制器
ret = s3c24xx_i2c_init(i2c);    
if (ret != 0)
    goto err_iomap;

// 获取IRQ资源
i2c->irq = ret = platform_get_irq(pdev, 0);   
if (ret <= 0) {
    dev_err(&pdev->dev, "cannot find IRQ\n");
    goto err_iomap;
}

// 申请IRQ (裸机一般使用查询法来判断从机的响应，而内核一般采用中断方式等待从机响应)
ret = request_irq(i2c->irq, s3c24xx_i2c_irq, IRQF_DISABLED,
          dev_name(&pdev->dev), i2c);

把关注点放在初始化I2C控制器的s3c24xx_i2c_init函数和申请IRQ上。

static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
{
    unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
    struct s3c2410_platform_i2c *pdata;
    unsigned int freq;

    /* get the plafrom data */

    pdata = i2c->dev->platform_data;

    /* inititalise the gpio */

    if (pdata->cfg_gpio)
        pdata->cfg_gpio(to_platform_device(i2c->dev));      // 设置I2C对应的管脚

    /* write slave address */
    // 设置I2C控制器作为从设备时的地址
    writeb(pdata->slave_addr, i2c->regs + S3C2410_IICADD);  

    dev_dbg(i2c->dev, "slave address 0x%02x\n", pdata->slave_addr);

    writel(iicon, i2c->regs + S3C2410_IICCON);        // 使能 Tx/Rx Interrupt 和 ACK信号

    /* we need to work out the divisors for the clock... */

    // 配置I2C的时钟频率
    if (s3c24xx_i2c_clockrate(i2c, &freq) != 0) {
        writel(0, i2c->regs + S3C2410_IICCON);
        dev_err(i2c->dev, "cannot meet bus frequency required\n");
        return -EINVAL;
    }

    /* todo - check that the i2c lines aren't being dragged anywhere */

    dev_dbg(i2c->dev, "bus frequency set to %d KHz\n", freq);
    dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02lx\n", iicon);

    dev_dbg(i2c->dev, "S3C2440_IICLC=%08x\n", pdata->sda_delay);
    writel(pdata->sda_delay, i2c->regs + S3C2440_IICLC);

    return 0;
}

可以看到设置I2C对应的管脚是调用平台数据中的cfg_gpio，其实看到这里如果还有印象的话就能反应出来这是在调用s3c_i2c0_set_platdata中设置的。该函数还设置了I2C控制器的从地址，该地址用来在控制器作为从地址时使用，但是这种情况的出现微乎其微。除此之外使能Tx/Rx Interrupt和ACK信号，配置了I2C的时钟频率。

注意从前一段分析中得知，内核中I2C采用中断方式等待从机响应，所以probe函数这一段代码中申请了IRQ并绑定了中断处理函数s3c24xx_i2c_irq。

static irqreturn_t s3c24xx_i2c_irq(int irqno, void *dev_id)
{
    struct s3c24xx_i2c *i2c = dev_id;
    unsigned long status;
    unsigned long tmp;

    // 获取I2CSTAT寄存器的值
    status = readl(i2c->regs + S3C2410_IICSTAT);

    if (status & S3C2410_IICSTAT_ARBITR) {   // I2C总线仲裁失败
        /* deal with arbitration loss */
        dev_err(i2c->dev, "deal with arbitration loss\n");
    }

    if (i2c->state == STATE_IDLE) {
        dev_dbg(i2c->dev, "IRQ: error i2c->state == IDLE\n");

        tmp = readl(i2c->regs + S3C2410_IICCON);
        tmp &= ~S3C2410_IICCON_IRQPEND;
        writel(tmp, i2c->regs +  S3C2410_IICCON);
        goto out;
    }

    /* pretty much this leaves us with the fact that we've
     * transmitted or received whatever byte we last sent */

    // 处理I2C的收发数据
    i2c_s3c_irq_nextbyte(i2c, status);

 out:
    return IRQ_HANDLED;
}

具体也不展开分析了，但是要注意的是有这么一条线：该中断处理函数调用了i2c_s3c_irq_nextbyte，然后内部调用了s3c24xx_i2c_stop，再内部调用了s3c24xx_i2c_master_complete，最后再内部执行了一个关键代码wake_up(&i2c->wait);，这就是通过中断方式唤醒之前在发送数据时进行的睡眠等待。

回到probe函数，最后分析重头戏。

ret = i2c_add_numbered_adapter(&i2c->adap);
if (ret < 0) {
    dev_err(&pdev->dev, "failed to add bus to i2c core\n");
    goto err_cpufreq;
}

该代码将I2C适配器注册到了内核中。i2c_add_numbered_adapter函数由核心层提供，其定义位于I2C核心层drivers/i2c/i2c-core.c中，用来注册I2C适配器。其实在内核中提供了两个adapter注册接口,分别为i2c_add_adapter和i2c_add_numbered_adapter由于在系统中可能存在多个adapter, 所以将每一条I2C总线(控制器)对应一个编号，这个总线号（可以称这个编号为总线号码）与PCI中的总线号不同。它和硬件无关, 只是软件上便于区分而已。对于i2c_add_adapter而言, 它使用的是动态总线号, 即由系统给其分配一个总线号, 而i2c_add_numbered_adapter则是自己指定总线号, 如果这个总线号非法或者是被占用, 就会注册失败。不管哪个注册接口，其核心都是调用i2c_register_adapter函数来进行真正的注册。取出i2c_register_adapter函数的关键部分进行分析。

res = device_register(&adap->dev);

if (adap->nr < __i2c_first_dynamic_bus_num)
    i2c_scan_static_board_info(adap);

dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap,
             __process_new_adapter);

device_register(&adap->dev);表示主机适配器adapter的注册。

i2c_scan_static_board_info(adap);内部先遍历__i2c_board_list取出板卡信息（描述的是板子上的I2C外设的信息，即I2C从机的信息），该链表的生成是在arch/arm/mach-s5pv210/mach-x210.c中进行的，在mach-x210.c中的smdkc110_machine_init函数中进行了除之前分析的调用s3c_i2c0_set_platdata外，还调用了i2c_register_board_info对板卡信息进行了注册。

int __init
i2c_register_board_info(int busnum,
    struct i2c_board_info const *info, unsigned len)
{
    int status;

    down_write(&__i2c_board_lock);

    /* dynamic bus numbers will be assigned after the last static one */
    // __i2c_first_dynamic_bus_num为全局未显式初始化变量，所以第一次进到这个函数，值为0
    if (busnum >= __i2c_first_dynamic_bus_num)
        __i2c_first_dynamic_bus_num = busnum + 1;

    for (status = 0; len; len--, info++) {
        struct i2c_devinfo  *devinfo;

        devinfo = kzalloc(sizeof(*devinfo), GFP_KERNEL);
        if (!devinfo) {
            pr_debug("i2c-core: can't register boardinfo!\n");
            status = -ENOMEM;
            break;
        }

        devinfo->busnum = busnum;
        devinfo->board_info = *info;
        list_add_tail(&devinfo->list, &__i2c_board_list);    // 将board_info用链表管理起来 
    }

    up_write(&__i2c_board_lock);

    return status;
}

板卡信息的描述，主要对其设备名和从地址进行赋值，示例如下

#define I2C_BOARD_INFO(dev_type, dev_addr) \
    .type = dev_type, .addr = (dev_addr)

#ifdef CONFIG_TOUCHSCREEN_GSLX680
    {
        I2C_BOARD_INFO("gslX680", 0x40),  // 主要对其设备名和从地址进行赋值
    },
#endif

然后在i2c_scan_static_board_info内部利用板卡信息作为原料调用i2c_new_device来创建了client，表示从机设备，并将adapter挂接到了client结构体内部的指针上。i2c_scan_static_board_info代码如下。

static void i2c_scan_static_board_info(struct i2c_adapter *adapter)
{
    struct i2c_devinfo  *devinfo;

    down_read(&__i2c_board_lock);
    // __i2c_board_list在调用i2c_register_board_info时链接起来的
    list_for_each_entry(devinfo, &__i2c_board_list, list) {
        if (devinfo->busnum == adapter->nr
                && !i2c_new_device(adapter,
                        &devinfo->board_info))
            dev_err(&adapter->dev,
                "Can't create device at 0x%02x\n",
                devinfo->board_info.addr);
    }
    up_read(&__i2c_board_lock);
}

创建完client后，回到i2c_register_adapter函数，最后执行了dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter);，该函数是遍历在I2C总线上已经注册的driver，通过回调__process_new_adapter函数的方式，遍历到i2c-dev这个通用驱动后就会用其i2cdev_attach_adapter方法来挂接到在i2c-dev中注册的字符设备驱动，并使用这个字符设备驱动的主设备号和adapter中的总线号（作为次设备号）来创建名为i2c-x的设备节点，应用层访问这个设备节点后即可调用在i2c-dev中注册的file_operations中的操作方法，从操作方法源码知，最终读写调用的是adapter中的读写方法（即在本平台中为i2c-s3c2410.c中定义的方法）。下面对其进行验证。

__process_new_adapter展开如下

static int i2c_do_add_adapter(struct i2c_driver *driver,
                  struct i2c_adapter *adap)
{
    /* Detect supported devices on that bus, and instantiate them */
    i2c_detect(adap, driver);

    /* Let legacy drivers scan this bus for matching devices */
    if (driver->attach_adapter) {
        /* We ignore the return code; if it fails, too bad */
        driver->attach_adapter(adap);   // 调用i2c-dev中的i2cdev_attach_adapter方法
    }
    return 0;
}

static int __process_new_adapter(struct device_driver *d, void *data)
{
    return i2c_do_add_adapter(to_i2c_driver(d), data);
}

可以看到driver->attach_adapter(adap);，的确是调用I2C总线下的驱动中的attach_adapter方法，到了这里在I2C设备驱动层埋下的悬念终于要水落石出了（不容易啊啊啊啊啊啊），穿越回到I2C设备驱动层进行分析，进入drivers/i2c/i2c-dev.c分析i2cdev_attach_adapter方法。

static int i2cdev_attach_adapter(struct i2c_adapter *adap)
{
    struct i2c_dev *i2c_dev;
    int res;

    i2c_dev = get_free_i2c_dev(adap);
    if (IS_ERR(i2c_dev))
        return PTR_ERR(i2c_dev);

    /* register this i2c device with the driver core */
    /* 使用主设备号和adapter中的总线号（作为次设备号）来创建名为i2c-x的设备节点 */
    i2c_dev->dev = device_create(i2c_dev_class, &adap->dev,
                     MKDEV(I2C_MAJOR, adap->nr), NULL,
                     "i2c-%d", adap->nr);
    if (IS_ERR(i2c_dev->dev)) {
        res = PTR_ERR(i2c_dev->dev);
        goto error;
    }
    res = device_create_file(i2c_dev->dev, &dev_attr_name);
    if (res)
        goto error_destroy;

    pr_debug("i2c-dev: adapter [%s] registered as minor %d\n",
         adap->name, adap->nr);
    return 0;
error_destroy:
    device_destroy(i2c_dev_class, MKDEV(I2C_MAJOR, adap->nr));
error:
    return_i2c_dev(i2c_dev);
    return res;
}

i2c_dev->dev = device_create(i2c_dev_class, &adap->dev, MKDEV(I2C_MAJOR, adap->nr), NULL, "i2c-%d", adap->nr);使用主设备号和adapter中的总线号（作为次设备号）来创建名为i2c-x的设备节点。

static ssize_t i2cdev_write(struct file *file, const char __user *buf,
        size_t count, loff_t *offset)
{
    int ret;
    char *tmp;
    // 取出i2c_client
    struct i2c_client *client = file->private_data;

    if (count > 8192)
        count = 8192;

    tmp = kmalloc(count, GFP_KERNEL);
    if (tmp == NULL)
        return -ENOMEM;
    // 拷贝用户数据到内核空间
    if (copy_from_user(tmp, buf, count)) {
        kfree(tmp);
        return -EFAULT;
    }

    pr_debug("i2c-dev: i2c-%d writing %zu bytes.\n",
        iminor(file->f_path.dentry->d_inode), count);

    // 发送I2C数据
    ret = i2c_master_send(client, tmp, count);
    kfree(tmp);
    return ret;
}

以write函数为例，可以看到写数据通过ret = i2c_master_send(client, tmp, count);完成的。

int i2c_master_send(struct i2c_client *client, const char *buf, int count)
{
    int ret;
    // 获取I2C适配器
    struct i2c_adapter *adap = client->adapter;
    struct i2c_msg msg;

    // 封装I2C数据包
    msg.addr = client->addr;
    msg.flags = client->flags & I2C_M_TEN;   // 发送标志位
    msg.len = count;
    msg.buf = (char *)buf;

    // 发送I2C数据包
    ret = i2c_transfer(adap, &msg, 1);

    /* If everything went ok (i.e. 1 msg transmitted), return #bytes
       transmitted, else error code. */
    return (ret == 1) ? count : ret;
}

可以看到，经过I2C数据包的封装后，真正的最终写数据通过ret = i2c_transfer(adap, &msg, 1);完成的。进入到i2c_transfer函数，截取关键部分。

for (ret = 0, try = 0; try <= adap->retries; try++) {
    // 调用具体的SoC的I2C总线驱动的发送方法
    ret = adap->algo->master_xfer(adap, msgs, num);
    if (ret != -EAGAIN)
        break;
    if (time_after(jiffies, orig_jiffies + adap->timeout))
        break;
}

山回路转不见君，雪上空留马行处。

adap->algo->master_xfer(adap, msgs, num);终于回到了原点见到了I2C总线驱动层中定义的操作方法。

可以看到过程的确如上文所说，表现为从I2C总线驱动层自底向上后又由自顶向下的调用流程，简直一跃千里后又倾泻而下。

I2C特定设备驱动分析

笔者以S5PV210的E2PROM驱动为例讲解, 源码见github链接。

struct e2prom_device {
    struct i2c_client *at24c02_client;   /* I2C client(从设备) */
    /* class和device用来自动创建设备节点 */
    struct class      *at24c02_class;
    struct device     *at24c02_device;
};

struct e2prom_device *e2prom_dev;

封装一个e2prom_device结构体表示对E2PROM的抽象，其中包含I2C client（用来表示I2C从设备）以及class和device（这两者单纯是用来自动创建设备节点的）。

struct i2c_device_id e2prom_table[] = {
    [0] = {
        .name         = "24c02",
        .driver_data  = 0,
    },
    [1] = {
        .name         = "24c08",
        .driver_data  = 0,
    },
};

/* I2C设备驱动 */
struct i2c_driver e2prom_driver = {
    .probe     =  e2prom_probe,
    .remove    =  e2prom_remove,
    .id_table  =  e2prom_table,
    .driver    = {
        .name = "e2prom",
    },
};

static int __init e2prom_init(void)
{
    return i2c_add_driver(&e2prom_driver);   /* 注册I2C设备驱动 */
}

先是调用i2c_add_driver注册I2C设备驱动。根据上文在I2C核心层的源码分析可知，会通过在核心层中注册的i2c_bus_type下的i2c_device_match函数来匹配设备与驱动，一旦匹配上则会调用其i2c_device_probe函数，而i2c_device_probe函数又会调用i2c_driver的probe函数。注意如上文分析所知，client生成的原料为board_info，所以要使这个驱动成功匹配，需要在arch/arm/mach-s5pv210/mach-x210.c中使用i2c_register_board_info来注册board_info。接下去直奔prob函数进行分析。

struct file_operations e2prom_fops = {
    .owner = THIS_MODULE,
    .open  = e2prom_open,
    .write = e2prom_write,
    .read =  e2prom_read,
};

static int e2prom_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
    int ret;

    printk(KERN_INFO "e2prom probe!\n");
    e2prom_dev = kmalloc(sizeof(struct e2prom_device), GFP_KERNEL);
    if (!e2prom_dev) {
        printk(KERN_ERR "malloc failed!\n");
        return -ENOMEM;
    }

    e2prom_dev->at24c02_client = client;

    /* 注册为字符设备驱动 */
    ret = register_chrdev(E2PROM_MAJOR, "e2prom_module", &e2prom_fops);
    if (ret < 0) {
        printk(KERN_ERR "malloc failed\n");
        ret = -ENOMEM;
        goto err0;
    }

    /* 创建类  */
    e2prom_dev->at24c02_class = class_create(THIS_MODULE, "e2prom_class");
    if (IS_ERR(e2prom_dev->at24c02_class)) {
        printk(KERN_ERR "class create failed!\n");
        ret = PTR_ERR(e2prom_dev->at24c02_class);
        goto err1;
    }

    /* 在类下创建设备 */
    e2prom_dev->at24c02_device = device_create(e2prom_dev->at24c02_class, NULL, MKDEV(E2PROM_MAJOR, 0), NULL, "at24c08");
    if (IS_ERR(e2prom_dev->at24c02_device)) {
        printk(KERN_ERR "class create failed!\n");
        ret = PTR_ERR(e2prom_dev->at24c02_device);
        goto err1;
    }

    return 0;
err1:
    unregister_chrdev(E2PROM_MAJOR, "e2prom_module");
err0:
    kfree(e2prom_dev);
    ret

在probe函数中调用register_chrdev函数来将E2PROM驱动注册为了字符设备驱动，并绑定了fops。然后调用class_create和device_create自动生成设备节点。

static int e2prom_open(struct inode *inode, struct file *file)
{
    return 0;
}

open方法为空，以write方法为例讲解具体的操作，read方法类似。

static ssize_t e2prom_write(struct file *file, const char __user *buf,
        size_t size, loff_t *offset)
{
    int ret = 0;
    char *tmp;
    tmp = kmalloc(size, GFP_KERNEL);
    if (tmp == NULL) {
        printk(KERN_ERR "mallo failed!\n");
        return -ENOMEM;
    }

    /* 将用户空间数据拷贝到内核空间 */
    ret = copy_from_user(tmp, buf, size);
    if (ret) {
        printk("copy data faile!\n");
        goto err0;
    }

    /* I2C write */
    ret = i2c_write_byte(tmp, size);
    if (ret) {
        printk(KERN_ERR "wrtie byte failed!\n");
        goto err0;
    }

    kfree(tmp);
    return size;

err0:
    kfree(tmp);
    return -EINVAL;
}

可以看到真正的操作I2C在i2c_write_byte函数。

static int i2c_write_byte(char *buf, int count)
{
    int ret = 0;
    struct i2c_msg msg;

    /* 封装I2C数据包 */
    msg.addr   = e2prom_dev->at24c02_client->addr; /* I2C从设备地址 */
    msg.flags  = 0;                                /* write flag */
    msg.len    = count;                            /* 数据长度 */
    msg.buf    = buf;                              /* 写入的数据 */

    /* 调用I2C核心层提供的传输函数，其本质还是调用的I2C总线驱动(主机控制器驱动)层下实现的algo->master_xfe方法 */
    ret = i2c_transfer(e2prom_dev->at24c02_client->adapter, &msg, 1);
    if (ret < 0) {
        printk(KERN_ERR "i2c transfer failed!\n");
        return -EINVAL;
    }
    return ret;
}

可以看到是调用在I2C核心层提供的传输函数，其本质还是在传输函数内部调用了跟具体SoC相关的I2C主机控制器操作方法中的传输方法。该函数接口需要提供一个i2c_msg，所以对其进行了创建并填充，注意msg.flags = 0;中0表示写，1表示读。

终了，撒花！！！✿✿✿ ～

用Python写Shell脚本

2019-06-12T03:53:20.000Z

Python调用Shell命令

os.system

os.system函数与系统编程中的exec族函数调用一致，创建出子进程后代码段由外部程序替换，不会返回外部程序运行结果。

1
2
3

import os

os.system('ls -l')

os.popen

os.popen返回的是一个文件对象，它将外部程序运行结果保存在文件对象中，当调用其read方法时就会得到运行结果。该方法可以得到外部程序的运行结果。

import os

os.popen('ls -l').read()

res = os.popen('ls').read()
if 'a.c' in res:
    print('a.c in this')
else:
    print('a.c not in this')

commands.getoutput

commands模块只能在Python2中使用，Python3将其移除了。commands.getoutput方法直接将外部程序的输出结果作为字符串返回了。

import commands

commands.getoutput('ls -l')        # 返回输出结果
commands.getstatusoutput('ls -l')  # 返回(状态码， 输出结果)

subprocess.call

Python3中引入的模块，在Python3中推荐使用该模块。subprocess.call会将外部程序的输出结果输出并返回状态码。

from subprocess improt call

# 可以将命令和参数以列表的形式传入
code = call(['ls', '-l', '-a'])

# 也可以用字符串作为传入的参数（通过设置参数shell=True）
code = call('ls -l -a', shell=True)

文件操作API

创建文件

import os

# touch a.c
file = open('a.c', 'w')
file.close()

# mkdir dir
os.mkdir('dir')

# mkdir -p dir1/dir2
os.mkdirs('dir1/dir2')

# ln a.c b.c
os.link('a.c', 'b.c')

# ln -s a.c b.c
os.symlink('a.c', 'b.c')

删除文件

import os

# rm a.c
os.remove('a.c')

# rm -r dir
os.rmdir('dir')

复制文件

import shutil

# 参数src为源文件名字，参数dst为目标文件或目录名字
# shutil.copy(src, dst)
# shutil.copy2(src, dst)

# cp a.c b.c
shutil.copy('a.c', 'b.c')

# cp a.c dir/b.c
shutil.copy('a.c', 'dir/')

# cp -p a.c b.c
shutil.copy2('a.c', 'b.c')

# 参数src为源目录名字，dst为目标目录名字
# shutil.copytree(srd, dst)

# cp dir1 dir2 -r
shutil.copytree('dir1', 'dir2')

移动文件或重命名

import shutil

# shutil.move(src, dst)

# mv a.c b.c
shutil.move('a.c', 'b.c')

其他

import os

# 切换当前工作目录到/home/ifantsai/下
os.chdir('/home/ifantsai/')

# 返回当前工作目录
work_path = os.getcwd()

# 改变当前进程的根目录为当前目录
os.chroot('./')

# 改变a.c的权限为777
os.chmod('a.c', os.S_IRWXU or os.S_IRWXG or os.S_IRWXO)

# 改变文件的属主
os.chown('a.c', uid, gid)

# 返回b.c这个符号链接所指向的路径
path = os.readlink('b.c')

注: 路径相关操作在os.path模块中。命令行参数在sys模块中, sys.argc为参数个数，sys.argv为参数列表，其中sys.argv[0]为程序本身

Linux驱动之Input子系统剖析

2019-06-06T07:58:08.000Z

为了对多种不同类型的输入设备进行统一的处理，内核在字符设备驱动上抽象出一层，即输入子系统。

输入子系统由三部分组成：

事件驱动层
输入核心层
设备驱动层

事件驱动层负责处理和应用程序的接口，向应用程序提供简单的、统一的事件接口。

设备驱动层负责与底层输入设备的通信。

输入核心层负责各个结构体的注册以及事件驱动层与设备驱动层的数据传递。

事件驱动层是内核提供的，对所有输入类设备都是通用的，内核里已经支持所有的事件驱动。而驱动开发则只需针对具体输入设备实现设备驱动。

三个重要结构体

都定义在include/linux/input.h中。

struct input_dev: 对输入设备的抽象描述，继承自struct device
struct input_handler: 代表输入设备的处理方法
struct input_handle: 用来关联某个input_dev和input_handler

struct input_dev

input_dev 代表底层的输入设备，比如按键或鼠标，所有输入设备的input_dev对象保存在一个全局的input_dev链表里。

struct input_handler

input_handler 代表某个输入设备的处理方法，比如evdev就是专门处理输入设备产生的事件，所有的input_handler对象保存在一个全局的input_handler链表里。

struct input_handle

一个input_dev可以有多个input_handler，比如鼠标可以由evdev和mousedev来处理它产生的输入；同样，一个input_handler可以用于多种输入设备的事件处理。由于这种多对多关系的存在，所以需要将input_dev和input_handler关联起来，而input_handle就是用来关联两者的。每个input_handle都会产生一个设备文件节点，比如/dev/input 下的四个文件event0~3。通过input_handle就可以找到对应的input_dev和input_handler。

源码分析

笔者会大体上对input子系统的源码进行分析，如若分析的有出入，还望指出。在分析之前，以一张input整体架构图来呈现整个输入设备到用户空间的数据传递。

事件驱动层

内核在事件驱动层中实现了一个输入设备通用的事件驱动，即evdev，其实现在driver/input/evdev.c中。无论是按键、触摸屏还是鼠标，都会通过evdev进行输入事件的处理。比如鼠标，如果用户空间读取的是evdev提供的设备节点，则上报的是一个未经处理的通用于所有输入设备的事件，而mousedev则会对输入事件进行处理从而上报的是鼠标特有的事件。笔者从evdev.c入手分析。

static int __init evdev_init(void)
{
    return input_register_handler(&evdev_handler);
}

通过调用input_register_handler函数进行了evdev_handler的注册。evdev_handler是struct input_handler的实例对象。

static const struct input_device_id evdev_ids[] = {
    { .driver_info = 1 },   /* Matches all devices */
    { },            /* Terminating zero entry */
};

static struct input_handler evdev_handler = {
    .event      = evdev_event,
    .connect    = evdev_connect,
    .disconnect = evdev_disconnect,
    .fops       = &evdev_fops,
    .minor      = EVDEV_MINOR_BASE,
    .name       = "evdev",
    .id_table   = evdev_ids,
};

evdev_handler中描述了一些输入的处理函数以及与设备匹配用的id_table，在接下去的源码里会使用到。

现在进到input_register_handler函数里进行分析，以下是该函数所有源码，接下去会拆开分析。

input_register_handler函数

int input_register_handler(struct input_handler *handler)
{
   struct input_dev *dev;
   int retval;

   retval = mutex_lock_interruptible(&input_mutex);
   if (retval)
      return retval;

   INIT_LIST_HEAD(&handler->h_list);

   if (handler->fops != NULL) {
      // 每个事件驱动所支持的次设备号范围是[32 * n, 32 * n + 32)
      // 所以需要除于32来得到在input_table中的索引
      if (input_table[handler->minor >> 5]) {  
          // 重复注册，错误
          retval = -EBUSY;
          goto out;
      }
      // 将handler放入input_table
      input_table[handler->minor >> 5] = handler;
   }

   // 将handler放入input_handler_list链表中，表示注册了该handler
   list_add_tail(&handler->node, &input_handler_list);

   // 遍历已经注册的设备，匹配device和handler，
   // 匹配成功则调用handler->connect函数将device和handler关联成handle，
   // 然后进行设备的注册
   list_for_each_entry(dev, &input_dev_list, node)
      input_attach_handler(dev, handler);

   input_wakeup_procfs_readers();

   out:
   mutex_unlock(&input_mutex);
   return retval;
}

input_register_handler函数定义在input.c中，即现在进入到了输入核心层。

if (handler->fops != NULL) {
    // 每个事件驱动所支持的次设备号范围是[32 * n, 32 * n + 32)
    // 所以需要除于32来得到在input_table中的索引
    if (input_table[handler->minor >> 5]) {  
        // 重复注册，错误
        retval = -EBUSY;
        goto out;
    }
    // 将handler放入input_table
    input_table[handler->minor >> 5] = handler;
}

// 将handler放入input_handler_list链表中，表示注册了该handler
list_add_tail(&handler->node, &input_handler_list);

从evdev_handler的定义中可以看到handler->fops是有定义的，所以进入到子语句。这里解释一下handler->minor >> 5，内核中对每个事件驱动所支持的次设备号范围规定是[32 * n, 32 * n + 32)，比如mousedev的次设备号范围是[32, 64)、evdev的次设备号范围是[64, 96)等，相当于将次设备号以32个为一组对各种事件驱动进行了分类。该段代码就是找到正确的位置将handler放入input_table中，然后将handler放入input_handler_list链表中，表示注册了该handler。

1 2	list_for_each_entry(dev, &input_dev_list, node) input_attach_handler(dev, handler);

这段代码是在遍历已经注册的设备，在input_attach_handler函数里匹配device和handler，匹配成功则调用handler->connect函数将device和handler关联成handle，然后进行设备的注册，然后input_register_handler函数基本上执行完毕。

进到input_attach_handler函数里进行分析。

input_attach_handler函数

static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
{
   const struct input_device_id *id;
   int error;

   // 匹配input_handler和input_dev
   id = input_match_device(handler, dev);
   if (!id)
      return -ENODEV;

   // 匹配成功后，调用handler->connect将input_handler和input_dev绑定成input_handle
   error = handler->connect(handler, dev, id);
   if (error && error != -ENODEV)
      printk(KERN_ERR
          "input: failed to attach handler %s to device %s, "
          "error: %d\n",
          handler->name, kobject_name(&dev->dev.kobj), error);

   return error;
}

从代码中可以看出先是匹配input_handler和input_dev，匹配成功后则调用connect函数进行连接。

input_match_device函数

static const struct input_device_id *input_match_device(struct input_handler *handler, struct input_dev *dev)
{
   const struct input_device_id *id;
   int i;

   // 遍历input_hanlder的id_table，匹配input_dev
   for (id = handler->id_table; id->flags || id->driver_info; id++) {

       /* 严格匹配bus、vendor、product、version，前提是flag中有定义 */
       if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)
          if (id->bustype != dev->id.bustype)
              continue;

       if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
          if (id->vendor != dev->id.vendor)
              continue;

       if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
          if (id->product != dev->id.product)
              continue;

       if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
          if (id->version != dev->id.version)
              continue;
          
       // 严格匹配所有事件类型
       MATCH_BIT(evbit,  EV_MAX);
       /* 严格匹配所有事件的子事件 */
       MATCH_BIT(keybit, KEY_MAX);
       MATCH_BIT(relbit, REL_MAX);
       MATCH_BIT(absbit, ABS_MAX);
       MATCH_BIT(mscbit, MSC_MAX);
       MATCH_BIT(ledbit, LED_MAX);
       MATCH_BIT(sndbit, SND_MAX);
       MATCH_BIT(ffbit,  FF_MAX);
       MATCH_BIT(swbit,  SW_MAX);

       // 如果有定义handler->match函数，再调用handler->match进行匹配
       if (!handler->match || handler->match(handler, dev))
           return id;
   }
   return NULL;
}

从evdev_handler中的id_table的定义可以知道并没有定义任何flag和bit，所以这些严格匹配在evdev中都不会进行。而且handler->match为NULL，所以对于evdev而言这个函数并没有做什么，而是直接将id返回了。

回到input_attach_handler函数，最后在匹配成功后调用了handler->connect函数。这个connect函数实现在事件驱动层，所以回到evdev.c。

evdev_connect函数

static int evdev_connect(struct input_handler *handler, struct input_dev *dev,const struct input_device_id *id)
{
   struct evdev *evdev;
   int minor;
   int error;

   // 找到一个evdev_table中未使用的索引
   for (minor = 0; minor < EVDEV_MINORS; minor++)
      if (!evdev_table[minor])
          break;

   if (minor == EVDEV_MINORS) {
      printk(KERN_ERR "evdev: no more free evdev devices\n");
      return -ENFILE;
   }

   evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);
   if (!evdev)
      return -ENOMEM;

   INIT_LIST_HEAD(&evdev->client_list);
   spin_lock_init(&evdev->client_lock);
   mutex_init(&evdev->mutex);
   init_waitqueue_head(&evdev->wait);

   /* 初始化struct evdev */
   dev_set_name(&evdev->dev, "event%d", minor);
   evdev->exist = 1;
   evdev->minor = minor;

   evdev->handle.dev = input_get_device(dev);
   evdev->handle.name = dev_name(&evdev->dev);
   evdev->handle.handler = handler;
   evdev->handle.private = evdev;
                                         // EVDEV_MINOR_BASE + minor 生成真正的次设备号
   evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
   evdev->dev.class = &input_class;
   evdev->dev.parent = &dev->dev;
   evdev->dev.release = evdev_free;
   device_initialize(&evdev->dev);

   error = input_register_handle(&evdev->handle);   // 注册input_handle
   if (error)
      goto err_free_evdev;

   error = evdev_install_chrdev(evdev);
   if (error)
      goto err_unregister_handle;

   error = device_add(&evdev->dev);    // 注册设备，创建设备节点
   if (error)
       goto err_cleanup_evdev;

   return 0;

   err_cleanup_evdev:
   evdev_cleanup(evdev);  
   err_unregister_handle:
   input_unregister_handle(&evdev->handle);
   err_free_evdev:
   put_device(&evdev->dev);
   return error;
}

实例化了一个struct evdev对象，该结构体是对一个完整的evdev事件驱动的抽象描述。初始化struct evdev，将input_handler和input_dev关联起来形成input_handle，然后赋给evdev->handle，生成设备的设备号，向内核注册input_handle，最后注册设备以及创建设备节点。至此evdev的注册就结束了。

设备驱动层

以usbmouse.c为例分析鼠标的设备驱动，鼠标是挂载在usb总线下，笔者在这里将usb相关的代码忽略，只关心输入子系统有关的代码。根据Linux设备模型的原理，直接进入到usb_mouse_probe函数进行分析。

struct input_dev *input_dev;
input_dev = input_allocate_device();
input_dev->name = mouse->name;
input_dev->phys = mouse->phys;
usb_to_input_id(dev, &input_dev->id);
input_dev->dev.parent = &intf->dev;

input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
input_dev->keybit[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_LEFT) |
    BIT_MASK(BTN_RIGHT) | BIT_MASK(BTN_MIDDLE);
input_dev->relbit[0] = BIT_MASK(REL_X) | BIT_MASK(REL_Y);
input_dev->keybit[BIT_WORD(BTN_MOUSE)] |= BIT_MASK(BTN_SIDE) |
    BIT_MASK(BTN_EXTRA);
input_dev->relbit[0] |= BIT_MASK(REL_WHEEL);

input_set_drvdata(input_dev, mouse);

input_dev->open = usb_mouse_open;
input_dev->close = usb_mouse_close;

error = input_register_device(mouse->dev);

先实例化一个struct input_dev对象，然后进行相关初始化，struct input_dev成员中定义了一些位图，如下

unsigned long evbit[BITS_TO_LONGS(EV_CNT)];      // 描述设备所支持的事件类型
/* 描述设备所支持的相应事件的具体编码，或者可以看作是子事件 */
unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];    // 描述按键类型
unsigned long relbit[BITS_TO_LONGS(REL_CNT)];    // 描述相对坐标的类型
unsigned long absbit[BITS_TO_LONGS(ABS_CNT)];    // 描述绝对坐标的类型
unsigned long mscbit[BITS_TO_LONGS(MSC_CNT)];
unsigned long ledbit[BITS_TO_LONGS(LED_CNT)];
unsigned long sndbit[BITS_TO_LONGS(SND_CNT)];
unsigned long ffbit[BITS_TO_LONGS(FF_CNT)];
unsigned long swbit[BITS_TO_LONGS(SW_CNT)];

所以在初始化中还对evbit、keybit等成员进行了初始化，表示鼠标所支持的事件类型。最后调用input_register_device函数完成了鼠标设备的注册。

在usb_mouse_irq函数中进行事件的上报。

// data[0] & 0x01 取出最后一位，1表示按下，0表示未按下
input_report_key(dev, BTN_LEFT,   data[0] & 0x01);
input_report_key(dev, BTN_RIGHT,  data[0] & 0x02);
input_report_key(dev, BTN_MIDDLE, data[0] & 0x04);
input_report_key(dev, BTN_SIDE,   data[0] & 0x08);
input_report_key(dev, BTN_EXTRA,  data[0] & 0x10);

input_report_rel(dev, REL_X,     data[1]);
input_report_rel(dev, REL_Y,     data[2]);
input_report_rel(dev, REL_WHEEL, data[3]);

input_sync(dev);

关键部分就是调用input_report_key函数来上报按键信息，调用input_report_rel上报鼠标的相对位移，最后调用input_sync 来提交同步事件，告知input子系统，该设备已经提交了一个完整报告。

事件传递流程

设备驱动通过一系列input_report_xxx函数来上报事件，以input_report_key函数为例进行分析。

// 提交按键事件
static inline void input_report_key(struct input_dev *dev, unsigned int code, int value)
{
    input_event(dev, EV_KEY, code, !!value);
}

input_report_key函数调用的input_event函数，其实一系列上报函数（包括input_sync函数）都是调用的input_event函数。

void input_event(struct input_dev *dev,
         unsigned int type, unsigned int code, int value)
{
    unsigned long flags;

    if (is_event_supported(type, dev->evbit, EV_MAX)) {

        spin_lock_irqsave(&dev->event_lock, flags);
        add_input_randomness(type, code, value);
        input_handle_event(dev, type, code, value);
        spin_unlock_irqrestore(&dev->event_lock, flags);
    }
}

关键就是调用了input_handle_event函数，而input_handle_event函数中的关键就是下面代码

1 2	if (disposition & INPUT_PASS_TO_HANDLERS) input_pass_event(dev, type, code, value);

进到input_pass_event函数

static void input_pass_event(struct input_dev *dev,
                 unsigned int type, unsigned int code, int value)
{
    struct input_handler *handler;
    struct input_handle *handle;

    rcu_read_lock();

    handle = rcu_dereference(dev->grab);
    if (handle)
        handle->handler->event(handle, type, code, value);
    else {
        bool filtered = false;

        list_for_each_entry_rcu(handle, &dev->h_list, d_node) {
            if (!handle->open)
                continue;

            handler = handle->handler;
            if (!handler->filter) {
                if (filtered)
                    break;

                handler->event(handle, type, code, value);

            } else if (handler->filter(handle, type, code, value))
                filtered = true;
        }
    }

    rcu_read_unlock();
}

可以看到核心就是调用handler->event函数，以evdev为例，回到evdev.c中，进入到evdev_event函数中

client = rcu_dereference(evdev->grab);
if (client)
    evdev_pass_event(client, &event);
else
    list_for_each_entry_rcu(client, &evdev->client_list, node)
    evdev_pass_event(client, &event);

需要关心的部分是从evdev对象中取出了client对象（两者的挂接是在open时完成的），然后执行了evdev_pass_event(client, &event);（其中evdev是struct evdev的实例对象，是对一个完整的evdev事件驱动的抽象描述，其中struct evdev_client *grab成员管理该事件驱动下的所有client；client是struct evdev_client的实例对象，对于同一个设备，每打开一次就会实例化出一个该结构体的对象）

static void evdev_pass_event(struct evdev_client *client,
                 struct input_event *event)
{
    /*
     * Interrupts are disabled, just acquire the lock
     */
    spin_lock(&client->buffer_lock);
    wake_lock_timeout(&client->wake_lock, 5 * HZ);
    client->buffer[client->head++] = *event;
    client->head &= EVDEV_BUFFER_SIZE - 1;
    spin_unlock(&client->buffer_lock);

    if (event->type == EV_SYN)
        kill_fasync(&client->fasync, SIGIO, POLL_IN);
}

从上面代码可以看到将struct input_event的实例对象存进了client中的buffer里。struct evdev_client的定义如下

// 每打开一次设备就会实例化出该结构体
struct evdev_client {
    // buffer用来存储从设备驱动中提交上来的事件，
    // 当应用程序read设备文件时，事件驱动会把该buffer传递给应用层
    struct input_event buffer[EVDEV_BUFFER_SIZE]; 
    int head;
    int tail;
    spinlock_t buffer_lock; /* protects access to buffer, head and tail */
    struct fasync_struct *fasync;
    struct evdev *evdev;
    struct list_head node;
    struct wake_lock wake_lock;
    char name[28];
};

所以到此就清晰了事件从底层设备如何传递到事件驱动层的，事件驱动层的cline->buffer就是用来中转数据的，接下来我们关心事件是如何从事件驱动层传递给应用层。

以evdev.c为例，进入到handler中的fops中的open和read函数。

evdev_open函数主要做的是根据次设备号减去基地址得到索引，从evdev_table中取出evdev对象，然后实例化出一个client对象，将clinet对象绑定到evdev对象中。

evdev_read函数的核心部分如下

while (retval + input_event_size() <= count &&
       evdev_fetch_next_event(client, &event)) {

    if (input_event_to_user(buffer + retval, &event))
        return -EFAULT;

    retval += input_event_size();
}

evdev_fetch_next_event函数从client->buffer中取出从底层设备提交上来的事件赋给event，然后调用input_event_to_user函数将这个event传递给从用户层传下来的buffer，完成从事件驱动层到用户空间的数据传递。

客舍青青

k8s first commit 源码分析之 Cloudcfg

简介

命令行主体逻辑

rollingupdate操作

controller 操作

k8s first commit 源码分析之 API Server

获取 first commit 源码

简介

源码分析

Linux驱动之网卡驱动剖析

Linux 网络设备驱动架构

协议接口层

设备接口层

设备驱动功能层

源码分析

platform 框架分析

dm9000 open 过程分析

DM9000 发送过程分析

DM9000 接收过程分析

NAPI 方式接收介绍

公网环境搭建 k8s 集群

创建虚拟网卡

更新 /etc/hosts

关闭 swap 分区

配置 systemd 来管理 docker 的 cgroup

允许 iptables 检查桥接流量

开启相关端口

master 节点

worker 节点

所有节点

安装 kubeadm、kubelet 和 kubectl

修改 kubelet 启动参数

初始化 master 节点

修改kube-apiserver参数

安装 flannel 网络

worker 节点加入集群

测试

安装 Dashboard

Docker 入门之网络

默认网络模式

四种网络模式

自定义网络

Linux 同步机制之原子操作

AF_XDP socket 介绍

eBPF

XDP

AF_XDP

UMEM

上古神器 awk 笔记

awk基本格式

BEGIN 和 END 语句块

awkpattern 和 action

awk 读取文件

记录分隔符

行号

字段分割

内核链表介绍

传统链表的困境

数据和结构分离

内核链表

总结

OpenResty入门笔记

OpenResty 简介

安装

启停

opm常用命令

参考手册

rk3399-android9.0-secureboot介绍

Secureboot流程

pc加密过程

设备解密过程

AVB流程

Merkle Tree

hash list

hash tree

avbtool中建树源码分析

Express入门笔记

Node.js简述

安装

修改`kube-apiserver`参数

`awk`基本格式

`BEGIN` 和 `END` 语句块

`awk`pattern 和 action

`awk` 读取文件