by fanxiushu 2023-08-16 转载或引用请桌面原始作者。
实现linux平台的虚拟磁盘驱动，是为了要实现在linux远程无盘启动的。
linux平台下的无盘启动，现成的办法有许多，比如iSCSI，NFS，NBD等都可以，
不过我都没去试过，所以不清楚具体的细节。
但是可以肯定得是，比windows下实现无盘启动轻松，windows中也有现成的比如iSCSI办法，
不过 windows的中的iSCSI我也没有具体去实验过，
所以这里也得不出两个系统下的搭建无盘启动过程的难度对比情况。
上面说得iSCSI这些，都是操作系统本身集成的方案，
都是现成的，唯一需要去做的就是如何使用现成的东西，去搭建无盘启动的整个过程。
这中间不牵涉到程序的开发过程，顶多就是做一些脚本什么的方便维护。
而我这里说的是如何开发无盘启动的过程
（包括客户端驱动和服务器端，网络传输协议等都是自定义实现）。
在CSDN上前面的5,6篇文章，都是在阐述windows下的无盘启动开发内容，
其中以如何开发Legacy BIOS 和UEFI的引导程序讲述的比较详细，
其实最麻烦的还是windows下的驱动开发问题，
只是因为很早前讲述过windows中虚拟磁盘驱动开发，所以现在就省略了。
本章将介绍linux平台下的虚拟磁盘驱动开发过程。
为了增加一些兴趣，可以首先去查看我在windows平台下的无盘启动的演示视频：
win10系统的无盘启动过程-CSDN直播这是开发的虚拟驱动实现的win10平台下的无盘启动过程演示，在vmware中的演示效果。https://live.csdn.net/v/320536
无盘启动过程，演示的是win7平台和本地镜像启动-CSDN直播无盘启动的网络方式和本地镜像方式的演示视频https://live.csdn.net/v/314881
其中以win7的无盘启动最快，因为毕竟体积小（以前是觉得win7体积大，winxp小，现在是win7变小了）。
win10启动过程，我估计了一下，从UEFI引导程序调用bootmgr开始到进入到windows界面。
需要大约50秒时间。
当然这个时间跟具体的硬件配置有关，因为毕竟我这的电脑硬件配置，
在我的真实电脑上启动也得花个30-40秒的时间，现在网启也才多了10-20秒而已。
回到linux平台中的虚拟磁盘驱动开发上来。
其实linux中的磁盘驱动，本质上就是块设备驱动。
而在linux中分成三大类基本驱动类型：
1 字符设备驱动， 2 块设备驱动，3 网络设备驱动。
可想而知，磁盘驱动作为linux核心中基本类型，实现想必不会简单。
也确实，linux里边的关于块设备的核心代码确实比较复杂。
再回到windows，windows中关于磁盘相关的实现同样也是复杂的。
我只举个简单的层级例子： windows底层storport接口给程序员调用来实现具体的磁盘设备。
上层是disk.sys驱动实现底层磁盘设备的通用接口层，这个跟linux内核中 generic Block Layer 层基本是同一个概念。
再上层是partmgr.sys 实现对磁盘分区管理，再朝上是volmgr驱动负责每个分区卷的管理，
再然后就是对应的文件系统驱动，比如ntfs，fat等文件系统驱动。
linux内核中关于块设备也有同样的分层概念。
只是linux把这些一股脑儿的的塞进一个单一的linux内核中，而windows是以单独的模块来实现这些过程。
这里不阐述研究linux内核代码的事（这可是个相当绒长的，几百篇文章都可能研究不完），
而只是研究如何利用linux内核提供的接口，实现块设备驱动，从而达到实现我们的虚拟磁盘驱动的目的。
linux内核提供的块设备接口，那可真是太过于简单，
以至于总有种小孩子过家家一般的荒缪的感觉。
如下代码，就能实现一个内存磁盘的功能，代码却只有短短70多行。
（相同的简单功能，在windows中使用storport框架实现简单的内存磁盘，代码起码要到千行左右了，
而且还得编写inf配置文件，生成 cat签名文件，等等。反正不是在一个等级的）
int major;
int disk_size = 1024 * 1024;
char* memdisk = 0;
const char* DRIVER_NAME = "nbt_scsi";
spinlock_t queue_spinLock;
struct gendisk* disk = 0;
static const struct block_device_operations nbt_fops =
{
.owner = THIS_MODULE,
}
void disk_do_request(struct request_queue *q)
{
struct request *req;
while ((req = blk_fetch_request(q)) != NULL) {
BOOLEAN is_read;
int64_t offset;
long length;
struct req_iterator iter;
struct bio_vec *bvec;
///读写offset和length
offset = ((uint64_t)blk_rq_pos(req)) << 9;
length = blk_rq_bytes(req);
is_read = TRUE;
if (rq_data_dir(req) == WRITE) {
is_read = FALSE;
}
rq_for_each_segment(bvec, req, iter) { 查询request请求的所以数据块分段，
void *kaddr = kmap(bvec->bv_page);
char* buf = (char*)kaddr + bvec->bv_offset;
int len = bvec->bv_len;
///读写磁盘内容
if (is_read)memcpy(buf, memdisk + offset, len);
else memcpy(memdisk + offset, buf, len);
kunmap(bvec->bv_page);
offset += len;
}
__blk_end_request_all(req, 0); /// success complete request
}
}
static int __init blk_init(void)
{
spin_lock_init(&scsi->queue_spinLock);
major = register_blkdev(0, DRIVER_NAME);
///
memdisk = kmalloc(disk_size, GFP_KERNEL);
disk = alloc_disk(16);//创建
disk->major = major;
disk->first_minor = 0;
disk->fops = &nbt_fops;
set_capacity(disk, disk_size / 512); /// disk size
strcpy(disk->disk_name, "nbt-disk");
struct request_queue* q = blk_init_queue(disk_do_request, &queue_spinLock);
disk->queue = q;
add_disk(disk); 启动磁盘
return 0;
}
static void __exit blk_exit(void)
{
del_gendisk(disk);
blk_cleanup_queue(disk->queue);
put_disk(disk);
kfree(memdisk);
unregister_blkdev(scsi->major, DRIVER_NAME);
}
module_init(blk_init);
module_exit(blk_exit);
够简单的吧，不到100行代码，刚启蒙的小孩说不定都能做，哈哈。
大概的流程就是首先在初始化函数中调用 register_blkdev 注册块设备，
在退出函数中相应的使用un register_blkdev注销块设备。
然后就可以调用 alloc_disk 函数分配gendisk的结构体。
接着在gendisk中填充一些必须的参数，
包括上面代码中的 major，fops， queue，disk_name等参数。
其中 fops指向 block_device_operations 结构体，类似 字符设备中对应的操作回调函数，
不过呢，块设备的绝大部分操作函数都是linux内核帮我们实现了，
所以如果不是特别需求，都可以不填写，简单申明一个结构体就行。
然后就是设置 disk_name 块设备名字，这个名字对应 /dev目录下的名字，
再然后调用set_capacity 设置块设备的大小，
因为linux内核固定把 512字节当成一个块大小，所以实际磁盘大小除以512就行。
最后就比较重要的，磁盘读写问题，与字符设备不同，不是在操作回调函数中响应IO读写，
而是有一个专门的 queue来实现。
如上代码，使用 blk_init_queue 函数来创建一个队列，赋值给 gendisk的queue参数。
同时 blk_init_queue 函数需要提供一个回调函数，这个回调函数就会实现 磁盘的IO读写请求。
关于 queue问题，linux内核还实现一个读写方案，就是make request，
上面简单提到过， linux内核有个 generic Block Layer，处理通用的磁盘请求，
这一层，所有通信其实使用的是 bio 结构体传输数据的。
blk_init_queue 函数是传统的办法，会在generic block layer发送读写请求时候，
把一些相邻的bio请求合并起来，形成 request 请求，
然后再传输给 blk_init_queue提供的回调函数处理，
也就是相当于在 generic block layer 层和 block driver layer层的中间还有一个合并零散的bio的算法层。
而make request呢， 相当于略过了合并 bio请求的算法层，直接把bio请求发给 block driver。
这样做的好处也很明显，比如上面的内存磁盘，
其实到了 block driver layer也就是上面的代码disk_do_request回调函数中。
只需要简单内存拷贝（memcpy）就行，没必要浪费CPU再在算法层合并相邻 bio 请求。
所以make request 很适合 内存磁盘，SSD等响应非常快的磁盘系统。
至于make request如何调用，这里不再啰嗦，有兴趣可自行去查阅，反正也是很简单的几个函数而已。
到此，我们就轻轻松松的实现了linux系统下的磁盘设备了。
当然，严格来说，是实现了一个通用的块设备驱动，
作为通常的需求完全足够了，甚至作为linux的无盘启动来说，也已经足够了。
这个与windows平台完全不同，
linux下的这种 gendisk 通用的块设备驱动，其实在windows也有对应的实现方案：
windows驱动中，调用 IoCreateDevice 函数创建类型是 FILE_DEVICE_DISK 的设备，
然后响应 一些关于磁盘的特殊IOCTL， 同时响应 IRP_MG_READ和IRP_MJ_WRITE的读写磁盘扇区请求。
在应用层使用 DefineDosDevice等函数挂载，就能在应用层看到一个能被绝大部分程序访问的分区卷。
但是，在windows的这种做法，也就只能在应用层玩玩，在内核中基本不被承认，更不可能用它来作为启动磁盘了。
所以说，linux内核windows内核差别真的是非常大，驱动实现难度差别也是非常大。
通常来说，windows下的驱动开发更难。
上面说得linux通用块设备实现，
难道就没有更底层的接口，让我们的linux系统中的虚拟磁盘驱动看起来更像一块硬件磁盘，
而不是处于比较尴尬的通用块设备驱动的这一层。
当然是有的，自然最容易想到的就是基于 SCSI 接口的磁盘，
回到windows平台，windows的storport框架其实是从 winxp系统的scsiport框架升级发展而来，
storport可以实现任何底层协议的磁盘，不限于SCSI。
linux下也有对应的接口，毕竟SCSI是一个通用的接口层，比如U盘的上层协议就是基于SCSI的。
scsi接口比gendisk接口稍微麻烦点，但是总体来说还是很简单。
首先申明scsi_host_template 结构体。
类似下面这样，以下设置仅供参考，参数可以调整：
static struct scsi_host_template nbt_scsi_driver_template = {
///
.name = "Fanxiushu NetBoot Virtual SCSI Adapter",
.proc_name = "nbtscsi",
.info = nbt_scsi_info,
.queuecommand = nbt_scsi_queuecommand,
.change_queue_depth = nbt_scsi_change_queue_depth,
.eh_device_reset_handler = nbt_scsi_device_reset,
.bios_param = nbt_scsi_bios_parm,
.can_queue = 32,
.this_id = -1,
.sg_tablesize = SG_ALL,
.cmd_per_lun = 128,
.max_sectors = 8192,
.use_clustering = DISABLE_CLUSTERING,
.emulated = 1,
.module = THIS_MODULE,
};
其中 queuecommand 回调函数是最重要的。函数申明如下：
int nbt_scsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)；
它响应SCSI各种命令。
首先如下调用：
struct Scsi_Host *sh = scsi_host_alloc(&nbt_scsi_driver_template, sizeof(自己定义的私有结构体大小));
scsi_host_alloc 分配SCSI适配器对应的结构体。
接着调用 scsi_add_host(sh, dev ); 启动这个SCSI适配器，
这里dev对应着SCSI适配器总线设备，
但是我们创建的是一个虚拟磁盘驱动，没有真实的SCSI适配器硬件，所以是没有对应的device设备的。
该如何解决这个问题呢？
以前在讲述linux平台下实现虚拟USB控制器驱动的时候，就讲过，可以使用虚拟总线。
调用 platform_driver_register 注册一个平台总线，然后调用 platform_device_register注册一个总线设备。
这样在 probe回调函数中，就能获取到总线设备对应的device。
当scsi_host_alloc 和scsi_add_host调用之后，SCSI适配器就创建成功了。
接下来，就是创建具体的SCSI磁盘设备。
本来按照正常的硬件，我们接下来可以调用 scsi_scan_host 函数，从而触发系统扫描SCSI硬件适配器。
但是我们是虚拟驱动，所以没必要这么做，
直接调用 scsi_add_device 或者 __scsi_add_device 函数添加一个scsi磁盘设备就可以了。
调用scsi_add_device之后，linux内核就认为磁盘设备已经创建好。
这时候 scsi_host_template 里边对应的 queuecommand 回调函数就会被调用，用来处理具体的SCSI磁盘的SCSI请求。
至于queuecommand里边处理的SCSI命令，
这个就和windows下的驱动处理SCSI命令没啥本质区别（除了跟具体系统相关的之外）。
因为SCSI协议是跨平台通用的。
下图是linux下实现的scsi和通用块设备驱动演示图：
图中左边两个红色框里边对应的就是 SCSI接口的磁盘和基于gendisk的磁盘。
其中SCSI接口的磁盘在图中显示的跟底层硬件一样了。
除了vmware硬件设备之外，其它都显示是 Block Device 块设备。
可以与windows平台下对应的虚拟磁盘驱动做个对照：
在windows中，对网络通信做了非常多的工作，
如果只是普通的网络磁盘，没必要这么麻烦，直接使用WSK或TDI通信即可。
但是要作为启动磁盘，问题就比较大了，所以最终采用的是底层NDIS通信。
而linux的网络通信就没这么麻烦了，
非但不麻烦，可以说是非常简单，即便是作为linux启动盘也是一样的简单。
后面章节阐述我们自己的虚拟磁盘驱动实现 linux 下无盘启动的时候会讲述到。