linux内核 链表？linux最好用的系统

其实linux内核 链表的问题并不复杂，但是又很多的朋友都不太了解linux最好用的系统，因此呢，今天小编就来为大家分享linux内核 链表的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

Linux内核 klist 链表介绍

Linux内核中的链表形式多样，list_head作为通用的双向循环链表，功能强大且实现简单优雅。然而，当谈到链表的极致时，list_head并非唯一的选择。内核代码中至少还有两种链表形式，即hlist和klist，它们都是从list_head发展而来，用于特定的链表使用场景。

hlist：哈希表中的链表

hlist是专门为哈希表设计的链表形式。哈希表主要由哈希数组构成，为了解决映射冲突问题，通常将哈希数组的每一项设计为链表，以容纳重复的元素。然而，在稀疏的哈希表中，list_head的形式需要为每个链表头分配两个指针的空间，这在数据稀疏时是一种浪费。因此，hlist应运而生，它具有两个显著特点：每个链表头只需要一个指针，同时，每个节点都能找到自己的前一节点，形成双向链表，但不再循环。尽管hlist实现上可能有些绕，它通过直接指向指针地址来实现前一节点的链接，但实际上这种设计带来的实现便利远不及它在理解上的复杂性。

klist：设备驱动中的链表

klist是专门为适应设备驱动中特定情况而设计的链表形式。以设备链表为例，假设系统中存在多个设备，并通过链表进行组织。当某个线程命令卸载某设备时，即需要从设备链表中删除该设备，但实际情况是该设备当前正在使用中，此时若简单地通过加锁或阻塞线程等方式处理，显然不是最优解。考虑到设备的实际使用情况，klist提供了一种解决方案，即通过引用计数kref与链表节点相结合，当计数为零时，即可安全删除节点。

klist的结构与用法

klist由两个主要结构体组成：klist和klist_node。klist包含k_lock（用于链接节点的操作自旋锁）、k_list（嵌入的双向链表list）、get和put函数指针（用于增加和减少引用计数）。klist_node则包含了n_klist（指向链表头的指针）、n_node（嵌入的双向链表list）以及n_ref（引用计数器）。

链表遍历

链表遍历是klist的亮点之一，它能适应遍历过程中节点被删除的情况，并能忽略已被请求删除的节点。klist通过辅助结构struct klist_iter和四个函数实现链表的遍历。在遍历链表时，需要考虑线程在访问节点前可能已被唤醒，以及在减少前一个节点引用计数时可能将该节点删除的特殊情况。

klist的用武之地

klist主要用于设备驱动模型中，以适应动态变化的设备和驱动。它并不像list_head那样广泛适用，但其独特设计使其在特定场景下具有极高的效率和灵活性。klist的出现，展现了链表形式的多样性与创新性，对于那些需要高度松耦合、动态变化的系统设计来说，klist可能是一个更好的选择。如果你的系统中需要处理类似情况，不妨考虑使用klist，它可能能带来意想不到的效率提升和简化复杂性。

在x86体系下,进程控制块存放在内核空间的什么位置

linux驱动程序一般工作在内核空间，但也可以工作在用户空间。下面我们将详细解析，什么是内核空间，什么是用户空间，以及如何判断他们。

Linux简化了分段机制，使得虚拟地址与线性地址总是一致，因此，Linux的虚拟地址空间也为0~4G.Linux内核将这4G字节的空间分为两部分。将最高的1G字节(从虚拟地址0xC0000000到0xFFFFFFFF)，供内核使用，称为"内核空间".而将较低的3G字节(从虚拟地址 0x00000000到0xBFFFFFFF)，供各个进程使用，称为"用户空间)。因为每个进程可以通过系统调用进入内核，因此，Linux内核由系统内的所有进程共享。于是，从具体进程的角度来看，每个进程可以拥有4G字节的虚拟空间。

Linux使用两级保护机制：0级供内核使用，3级供用户程序使用。从图中可以看出(这里无法表示图)，每个进程有各自的私有用户空间(0~3G)，这个空间对系统中的其他进程是不可见的。最高的1GB字节虚拟内核空间则为所有进程以及内核所共享。

内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中。

虽然内核空间占据了每个虚拟空间中的最高1GB字节，但映射到物理内存却总是从最低地址(0x00000000)开始。对内核空间来说，其地址映射是很简单的线性映射，0xC0000000就是物理地址与线性地址之间的位移量，在Linux代码中就叫做PAGE_OFFSET.

内核空间和用户空间之间如何进行通讯？

内核空间和用户空间一般通过系统调用进行通信。

如何判断一个驱动是用户模式驱动还是内核模式驱动？判断的标准是什么？

用户空间模式的驱动一般通过系统调用来完成对硬件的访问，如通过系统调用将驱动的io空间映射到用户空间等。因此，主要的判断依据就是系统调用。

内核空间和用户空间上不同太多了，说不完，比如用户态的链表和内核链表不一样;用户态用printf,内核态用printk;用户态每个应用程序空间是虚拟的，相对独立的，内核态中却不是独立的，所以编程要非常小心。等等。

还有用户态和内核态程序通讯的方法很多，不单单是系统调用，实际上系统调用是个不好的选择，因为需要系统调用号，这个需要统一分配。

可以通过ioctl、sysfs、proc等来完成。

在进行设备驱动程序，内核功能模块等系统级开发时，通常需要在内核和用户程序之间交换信息。Linux提供了多种方法可以用来完成这些任务。本文总结了各种常用的信息交换方法，并用简单的例子演示这些方法各自的特点及用法。其中有大家非常熟悉的方法，也有特殊条件下方可使用的手段。通过对比明确这些方法，可以加深我们对Linux内核的认识，更重要的是，可以让我们更熟练驾御linux内核级的应用开发技术。

内核空间(kernel-space) VS用户空间(user-space)

作为一个Linux开发者，首先应该清楚内核空间和用户空间的区别。关于这个话题，已经有很多相关资料，我们在这里简单描述如下：

现代的计算机体系结构中存储管理通常都包含保护机制。提供保护的目的，是要避免系统中的一个任务访问属于另外的或属于操作系统的存储区域。如在IntelX86体系中，就提供了特权级这种保护机制，通过特权级别的区别来限制对存储区域的访问。基于这种构架，Linux操作系统对自身进行了划分：一部分核心软件独立于普通应用程序，运行在较高的特权级别上，（Linux使用Intel体系的特权级3来运行内核。）它们驻留在被保护的内存空间上，拥有访问硬件设备的所有权限，Linux将此称为内核空间。

相对的，其它部分被作为应用程序在用户空间执行。它们只能看到允许它们使用的部分系统资源，并且不能使用某些特定的系统功能，不能直接访问硬件，不能直接访问内核空间，当然还有其他一些具体的使用限制。（Linux使用Intel体系的特权级0来运行用户程序。）

从安全角度讲将用户空间和内核空间置于这种非对称访问机制下是很有效的，它能抵御恶意用户的窥探，也能防止质量低劣的用户程序的侵害，从而使系统运行得更稳定可靠。但是，如果像这样完全不允许用户程序访问和使用内核空间的资源，那么我们的系统就无法提供任何有意义的功能了。为了方便用户程序使用在内核空间才能完全控制的资源，而又不违反上述的特权规定，从硬件体系结构本身到操作系统，都定义了标准的访问界面。关于X86系统的细节，请查阅参考资料1

一般的硬件体系机构都提供一种“门”机制。“门”的含义是指在发生了特定事件的时候低特权的应用程序可以通过这些“门”进入高特权的内核空间。对于IntelX86体系来说，Linux操作系统正是利用了“系统门”这个硬件界面（通过调用int$0x80机器指令)，构造了形形色色的系统调用作为软件界面，为应用程序从用户态陷入到内核态提供了通道。通过“系统调用”使用“系统门”并不需要特别的权限，但陷入到内核的具体位置却不是随意的，这个位置由“系统调用”来指定，有这样的限制才能保证内核安全无虞。我们可以形象地描述这种机制：作为一个游客，你可以买票要求进入野生动物园，但你必须老老实实的坐在观光车上，按照规定的路线观光游览。当然，不准下车，因为那样太危险，不是让你丢掉小命，就是让你吓坏了野生动物。

出于效率和代码大小的考虑，内核程序不能使用标准库函数（当然还有其它的顾虑，详细原因请查阅参考资料2）因此内核开发不如用户程序开发那么方便。

内核空间和用户空间的相互作用

现在，越来越多的应用程序需要编写内核级和用户级的程序来一起完成具体的任务，通常采用以下模式：首先，编写内核服务程序利用内核空间提供的权限和服务来接收、处理和缓存数据；然后编写用户程序来和先前完成的内核服务程序交互，具体来说，可以利用用户程序来配置内核服务程序的参数，提取内核服务程序提供的数据，当然，也可以向内核服务程序输入待处理数据。

比较典型的应用包括: Netfilter(内核服务程序：防火墙)VS Iptable（用户级程序：规则设置程序）；IPSEC(内核服务程序：VPN协议部分)VS IKE(用户级程序：vpn密钥协商处理)；当然还包括大量的设备驱动程序及相应的应用软件。这些应用都是由内核级和用户级程序通过相互交换信息来一起完成特定任务的。

信息交互方法

用户程序和内核的信息交换是双向的，也就是说既可以主动从用户空间向内核空间发送信息，也可以从内核空间向用户空间提交数据。当然，用户程序也可以主动地从内核提取数据。下面我们就针对内核和用户交互数据的方法做一总结、归纳。

信息交互按信息传输发起方可以分为用户向内核传送/提取数据和内核向用户空间提交请求两大类，先来说说：

由用户级程序主动发起的信息交互。

（1）编写自己的系统调用

从前文可以看出，系统调用是用户级程序访问内核最基本的方法。目前linux大致提供了二百多个标准的系统调用，并且允许我们添加自己的系统调用来实现和内核的信息交换。比如我们希望建立一个系统调用日志系统，将所有的系统调用动作记录下来，以便进行入侵检测。此时，我们可以编写一个内核服务程序。该程序负责收集所有的系统调用请求，并将这些调用信息记录到在内核中自建的缓冲里。我们无法在内核里实现复杂的入侵检测程序，因此必须将该缓冲里的记录提取到用户空间。最直截了当的方法是自己编写一个新系统调用实现这种提取缓冲数据的功能。当内核服务程序和新系统调用都实现后，我们就可以在用户空间里编写用户程序进行入侵检测任务了，入侵检测程序可以定时、轮训或在需要的时候调用新系统调用从内核提取数据，然后进行入侵检测(具体步骤和代码参见Linux内核之旅网站电子杂志第四期)。

（2）编写驱动程序

Linux/UNIX的一个特点就是把所有的东西都看作是文件(every thing is a file)。系统定义了简洁完善的驱动程序界面，客户程序可以用统一的方法透过这个界面和内核驱动程序交互。而大部分系统的使用者和开发者已经非常熟悉这种界面以及相应的开发流程了。

驱动程序运行于内核空间，用户空间的应用程序通过文件系统中/dev/目录下的一个文件来和它交互。这就是我们熟悉的那个文件操作流程：open()—— read()()—— write()—— ioctl()——close()。（需要注意的是也不是所有的内核驱动程序都是这个界面，网络驱动程序和各种协议栈的使用就不大一致，比如说套接口编程虽然也有open()和close()等概念，但它的内核实现以及外部使用方式都和普通驱动程序有很大差异。）关于这部分的编程细节，请查阅参考资料3、4。

设备驱动程序在内核中要做的中断响应、设备管理、数据处理等等各种工作这篇文章不去关心，我们把注意力集中在它与用户级程序交互这一部分。操作系统为此定义了一种统一的交互界面，就是前面所说的open(), read(), write(), ioctl()和close()等等。每个驱动程序按照自己的需要做独立实现，把自己提供的功能和服务隐藏在这个统一界面下。客户级程序选择需要的驱动程序或服务（其实就是选择/dev/目录下的文件），按照上述界面和文件操作流程，就可以跟内核中的驱动交互了。其实用面向对象的概念会更容易解释，系统定义了一个抽象的界面（abstract interface），每个具体的驱动程序都是这个界面的实现（implementation）。

所以驱动程序也是用户空间和内核信息交互的重要方式之一。其实ioctl, read, write本质上讲也是通过系统调用去完成的，只是这些调用已被内核进行了标准封装，统一定义。因此用户不必像填加新系统调用那样必须修改内核代码，重新编译新内核，使用虚拟设备只需要通过模块方法将新的虚拟设备安装到内核中（insmod上）就能方便使用。关于此方面设计细节请查阅参考资料5，编程细节请查阅参考资料6。

在linux中，设备大致可分为：字符设备，块设备，和网络接口（字符设备包括那些必须以顺序方式，像字节流一样被访问的设备；如字符终端，串口等。块设备是指那些可以用随机方式，以整块数据为单位来访问的设备，如硬盘等；网络接口，就指通常网卡和协议栈等复杂的网络输入输出服务）。如果将我们的系统调用日志系统用字符型驱动程序的方式实现，也是一件轻松惬意地工作。我们可以将内核中收集和记录信息的那一部分编写成一个字符设备驱动程序。虽然没有实际对应的物理设备，但这并没什么问题：Linux的设备驱动程序本来就是一个软件抽象，它可以结合硬件提供服务，也完全可以作为纯软件提供服务（当然，内存的使用我们是无法避免的）。在驱动程序中，我们可以用open来启动服务，用read()返回处理好的记录，用ioctl()设置记录格式等，用close()停止服务，write()没有用到，那么我们可以不去实现它。然后在/dev/目录下建立一个设备文件对应我们新加入内核的系统调用日志系统驱动程序。

（3）使用proc文件系统

proc是Linux提供的一种特殊的文件系统，推出它的目的就是提供一种便捷的用户和内核间的交互方式。它以文件系统作为使用界面，使应用程序可以以文件操作的方式安全、方便的获取系统当前运行的状态和其它一些内核数据信息。

proc文件系统多用于监视、管理和调试系统，我们使用的很多管理工具如ps,top等，都是利用proc来读取内核信息的。除了读取内核信息，proc文件系统还提供了写入功能。所以我们也就可以利用它来向内核输入信息。比如，通过修改proc文件系统下的系统参数配置文件（/proc/sys），我们可以直接在运行时动态更改内核参数；再如，通过下面这条指令：

echo 1>/proc/sys/net/ip_v4/ip_forward

开启内核中控制IP转发的开关，我们就可以让运行中的Linux系统启用路由功能。类似的，还有许多内核选项可以直接通过proc文件系统进行查询和调整。

除了系统已经提供的文件条目，proc还为我们留有接口，允许我们在内核中创建新的条目从而与用户程序共享信息数据。比如，我们可以为系统调用日志程序（不管是作为驱动程序也好，还是作为单纯的内核模块也好）在proc文件系统中创建新的文件条目，在此条目中显示系统调用的使用次数，每个单独系统调用的使用频率等等。我们也可以增加另外的条目，用于设置日志记录规则，比如说不记录open系统调用的使用情况等。关于proc文件系统得使用细节，请查阅参考资料7。

（4）使用虚拟文件系统

有些内核开发者认为利用ioctl（）系统调用往往会似的系统调用意义不明确，而且难控制。而将信息放入到proc文件系统中会使信息组织混乱，因此也不赞成过多使用。他们建议实现一种孤立的虚拟文件系统来代替ioctl()和/proc，因为文件系统接口清楚，而且便于用户空间访问，同时利用虚拟文件系统使得利用脚本执行系统管理任务更家方便、有效。

我们举例来说如何通过虚拟文件系统修改内核信息。我们可以实现一个名为sagafs的虚拟文件系统，其中文件log对应内核存储的系统调用日志。我们可以通过文件访问特普遍方法获得日志信息：如

# cat/sagafs/log

使用虚拟文件系统——VFS实现信息交互使得系统管理更加方便、清晰。但有些编程者也许会说VFS的API接口复杂不容易掌握，不要担心2.5内核开始就提供了一种叫做libfs的例程序帮助不熟悉文件系统的用户封装了实现VFS的通用操作。有关利用VFS实现交互的方法看参考资料。

(5)使用内存映像

Linux通过内存映像机制来提供用户程序对内存直接访问的能力。内存映像的意思是把内核中特定部分的内存空间映射到用户级程序的内存空间去。也就是说，用户空间和内核空间共享一块相同的内存。这样做的直观效果显而易见：内核在这块地址内存储变更的任何数据，用户可以立即发现和使用，根本无须数据拷贝。而在使用系统调用交互信息时，在整个操作过程中必须有一步数据拷贝的工作——或者是把内核数据拷贝到用户缓冲区，或只是把用户数据拷贝到内核缓冲区——这对于许多数据传输量大、时间要求高的应用，这无疑是致命的一击：许多应用根本就无法忍受数据拷贝所耗费的时间和资源。

我们曾经为一块高速采样设备开发过驱动程序，该设备要求在20兆采样率下以1KHz的重复频率进行16位实时采样，每毫秒需要采样、DMA和处理的数据量惊人，如果要使用数据拷贝的方法，根本无法达成要求。此时，内存映像成为唯一的选择：我们在内存中保留了一块空间，将其配置成环形队列供采样设备DMA输出数据。再把这块内存空间映射到在用户空间运行的数据处理程序上，于是，采样设备刚刚得到并传送到主机上的数据，马上就可以被用户空间的程序处理。

实际上，内存映射方式通常也正是应用在那些内核和用户空间需要快速大量交互数据的情况下，特别是那些对实时性要求较强的应用。X window系统的服务器的虚拟内存区域，就可以被看做是内存映像用法的一个典型例子：X服务器需要对视频内存进行大量的数据交换，相对于lseek/write来说，将图形显示内存直接映射到用户空间可以显著提高效能。

并不是任何类型的应用都适合mmap，比如像串口和鼠标这些基于流数据的字符设备，mmap就没有太大的用武之地。并且，这种共享内存的方式存在不好同步的问题。由于没有专门的同步机制可以让用户程序和内核程序共享，所以在读取和写入数据时要有非常谨慎的设计以保证不会产生干绕。

mmap完全是基于共享内存的观念了，也正因为此，它能提供额外的便利，但也特别难以控制。

由内核主动发起的信息交互

在内核发起的交互中，我们最关心和感兴趣的应该是内核如何向用户程序发消息，用户程序又是怎样接收这些消息的，具体问题通常集中在下面这几个方面：内核可否调用用户程序？是否可以通过向用户进程发信号来告知用户进程事件发生？

前面介绍的交互方法最大的不同在于这些方式是由内核采取主动，而不是等系统调用来被动的返回信息的。

(1)从内核空间调用用户程序。

即使在内核中，我们有时也需要执行一些在用户级才提供的操作：如打开某个文件以读取特定数据，执行某个用户程序从而完成某个功能。因为许多数据和功能在用户空间是现有的或者已经被实现了，那么没有必要耗费大量的资源去重复。此外，内核在设计时，为了拥有更好的弹性或者性能以支持未知但有可能发生的变化，本身就要求使用用户空间的资源来配合完成任务。比如内核中动态加载模块的部分需要调用kmod。但在编译kmod的时候不可能把所有的内核模块都订下来（要是这样的话动态加载模块就没有存在意义了），所以它不可能知道在它以后才出现的那些模块的位置和加载方法。因此，模块的动态加载就采用了如下策略：加载任务实际上由位于用户空间的modprobe程序帮助完成——最简单的情形是modprobe用内核传过来的模块名字作为参数调用insmod。用这种方法来加载所需要的模块。

内核中启动用户程序还是要通过execve这个系统调用原形，只是此时的调用发生在内核空间，而一般的系统调用则在用户空间进行。如果系统调用带参数，那将会碰到一个问题：因为在系统调用的具体实现代码中要检查参数合法性，该检查要求所有的参数必须位于用户空间——地址处于0x0000000——0xC0000000之间，所以如果我们从内核传递参数（地址大于0xC0000000）,那么检查就会拒绝我们的调用请求。为了解决这个问题，我们可以利用set_fs宏来修改检查策略，使得允许参数地址为内核地址。这样内核就可以直接使用该系统调用了。

例如：在kmod通过调用execve来执行modprobe的代码前需要有set_fs(KERNEL_DS):

......

set_fs(KERNEL_DS);

/* Go, go, go...*/

if(execve(program_path, argv, envp)< 0)

return-errno;

上述代码中program_path为"/sbin/modprobe"，argv为{ modprobe_path,"-s","-k","--",(char*)module_name, NULL}，envp为{"HOME=/","TERM=linux","PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL}。

从内核中打开文件同样使用带参数的open系统调用，所需的仍是要先调用set_fs宏。

(2)利用brk系统调用来导出内核数据

内核和用户空间传递数据主要是用get_user(ptr)和put_user(datum,ptr)例程。所以在大部分需要传递数据的系统调用中都可以找到它们的身影。可是，如果我们不是通过用户程序发起的系统调用——也就是说，没有明确的提供用户空间内的缓冲区位置——的情况下，如何向用户空间传递内核数据呢？

显然，我们不能再直接使用put_user()了，因为我们没有办法给它指定目的缓冲区。所以，我们要借用brk系统调用和当前进程空间：brk用于给进程设置堆空间的大小。每个进程拥有一个独立的堆空间，malloc等动态内存分配函数其实就是进程的堆空间中获取内存的。我们将利用brk在当前进程(current process)的堆空间上扩展一块新的临时缓冲区，再用put_user将内核数据导出到这个确定的用户空间去。

还记得刚才我们在内核中调用用户程序的过程吗？在那里，我们有一个跳过参数检查的操作，现在有了这种方法，可以另辟蹊径了：我们在当前进程的堆上扩展一块空间，把系统调用要用到的参数通过put_user()拷贝到新扩展得到的用户空间里，然后在调用execve的时候以这个新开辟空间地址作为参数，于是，参数检查的障碍不复存在了。

char* program_path="/bin/ls";

/*找到当前堆顶的位置*/

mmm=current->mm->brk;

/*用brk在堆顶上原扩展出一块256字节的新缓冲区*/

ret= brk(*(void)(mmm+256));

/*把execve需要用到的参数拷贝到新缓冲区上去*/

put_user((void*)2,program_path,strlen(program_path)+1);

/*成功执行/bin/ls程序！*/

execve((char*)(mmm+2));

/*恢复现场*/

tmp= brk((void*)mmm);

这种方法没有一般性（具体的说，这种方法有负面效应吗），只能作为一种技巧，但我们不难发现：如果你熟悉内核结构，就可以做到很多意想不到的事情！

(3)使用信号

信号在内核里的用途主要集中在通知用户程序出现重大错误，强行杀死当前进程，这时内核通过发送SIGKILL信号通知进程终止，内核发送信号使用send_sign(pid,sig)例程，可以看到信号发送必须要事先知道进程序号（pid），所以要想从内核中通过发信号的方式异步通知用户进程执行某项任务，那么必须事先知道用户进程的进程号才可。而内核运行时搜索到特定进程的进程号是个费事的工作，可能要遍历整个进程控制块链表。所以用信号通知特定用户进程的方法很糟糕，一般在内核不会使用。内核中使用信号的情形只出现在通知当前进程（可以从current变量中方便获得pid）做某些通用操作，如终止操作等。因此对内核开发者该方法用处不大。

类似情况还有消息操作。这里不罗嗦了。

总结由用户级程序主动发起的信息交互，无论是采用标准的调用方式还是透过驱动程序界面，一般都要用到系统调用。而由内核主动发起信息交互的情况不多。也没有标准的界面，操作大不方便。所以一般情况下，尽可能用本文描述的前几种方法进行信息交互。毕竟，在设计的根源上，相对于客户级程序，内核就被定义为一个被动的服务提供者。因此，我们自己的开发也应该尽量遵循这种设计原则。

Linux 内核 10-list_head 和 hlist_head

在Linux内核中，数据管理采用两种双向链表类型：环形双向链表和具有表头的链型双向链表。

环形双向链表由list_head结构体组成，仅包含next和prev指针，分别指向下一个和前一个list_head结构体。其链表结构如图（a）所示。

具有表头的链型双向链表由hlist_head和hlist_node结构体构成，它们共同形成链表结构。hlist_head充当链表头节点，hlist_node作为元素节点。图（b）展示了它们的链表结构，其中next指向下一个hlist_node结构，而pprev指向后一个节点的next指针。

内核设计两种双向链表的原因在于它们各自拥有独特优势和适用场景。图（a）的链表适用于简单的双向链接结构，而图（b）的链表在处理具有头节点的链表时更为高效。

list_head链表

图（a）展示了list_head组成的双向链表结构，具有next和prev两个指针，分别指向下一个和前一个list_head结构体。此链表适用于不包含头节点的简单双向链表。

初始化链表有静态和动态两种方式。链表的插入、删除、替换、拼接等操作可通过特定函数实现。获取链表入口点通常使用container_of宏，它通过巧妙利用0指针获取结构体指针，从而访问成员。

遍历链表可借助于list_for_each_entry函数，通过传入所需结构体类型指针、链表头和结构体内struct list_head变量名来实现。

hlist_head和hlist_node链表

图（b）展示了hlist_head和hlist_node组成的双向链表结构，其中pprev指向前一个节点的next指针，以优化处理具有头节点的链表。

使用hlist_head和hlist_node的链表结构有助于简化链表操作，特别是在处理具有头节点的链表时，它们能提供更高效的方法。

总结

Linux内核中提供的两种双向链表类型，即环形双向链表和具有表头的链型双向链表，分别适用于不同场景。它们各自拥有独特优势，能够高效地处理数据存储和操作需求。