fanxiushu的专栏

struct Scsi_Host *sh = scsi_host_alloc(&nbt_scsi_driver_template, sizeof(自己定义的私有结构体大小));这时候 scsi_host_template 里边对应的 queuecommand 回调函数就会被调用，用来处理具体的SCSI磁盘的SCSI请求。然后响应 一些关于磁盘的特殊IOCTL， 同时响应 IRP_MG_READ和IRP_MJ_WRITE的读写磁盘扇区请求。

因此要在 boot-start 阶段正常进行网络通信，网卡驱动也必须是start==0， 而默认情况下，网卡驱动基本都是start=3，简单的说，Boot-Start阶段可以没有磁盘，但是必须在这个阶段建立起磁盘，能让windows进入下一个阶段前，正常访问磁盘。这是因为windows系统中，不同插槽位置，可能会生成不同的实例串，而一号插槽位置的网卡驱动生成的实例串与二号的不同。因此，作为windows系统盘的磁盘驱动，必定是在boot-start阶段（也就是注册表中start==0）的驱动。

EFI_BLOCK_DEVICE_PATH是我们自己定义的继承自 EFI_DEVICE_PATH 的路径，可直接定义成 MSG_VENDOR_DP 的方式。然后开发UEFI的引导程序，替换掉 原来的 EFI\boot\bootx64.efi就可以，之后就能让整个系统按照读取镜像文件的方式运行。因为在局域网环境中，丢包小的环境中，使用UDP反而更快，数据吞吐量更大，尤其是这种简单的一来一往的磁盘读写请求。所以在开发引导程序的时候，不必按照UEFI规范文档那样阐述的，制作符合UEFI规范的UEFI驱动程序，

前面两篇介绍传统BIOS引导程序的时候，讲述了开发传统BIOS引导程序的关键之处：HOOK BIOS INT13H 中断，替换中断服务函数。文章中还说过，这等于是16位模式下的另类的虚拟磁盘驱动。于是，在UEFI开发引导程序，基本上也是同样的开发思路：在UEFI环境下，实现一个虚拟磁盘驱动，这个虚拟磁盘驱动通过网络传输定位到服务器上的系统镜像。UEFI下的这个虚拟磁盘，会被当成一个正常的硬件，再然后，从这个虚拟磁盘找到ESP分区，找到 \EFI\Boot\bootx64.efi引导文件，加载

UDP发送函数，操作码是 PXENV_UNDI_TRANSMIT（0x08），发送的是包括MAC头在内的链路层数据，因此需要在发送前进行组包处理。UDP接收函数，操作码PXENV_UNDI_ISR（0x14），采用轮询方式接收，其实就是设置死循环查询，当然需要设置一个超时时间，从上文的asm汇编代码片段，在调用 Int13HookEntry 函数之前，压栈了一堆的寄存器，ax，bx。在使用pxe_call_api 基础函数，进一步封装实现UDP收发函数，比如 udp_recv和udp_send 函数之后，

而如果，我们把 13H中断的中断服务函数给替换掉，替换成我们的常驻内存的函数入口，而这个函数则通过PXE通信，把磁盘读写请求重定向到服务器端。这样不管是 MBR引导程序，ntldr，bootmgr等，通过INT 13H读写磁盘的时候，其实是通过我们的函数重定向到了服务器端。这个就是我们开发引导程序的最主要和核心的功能。其实，从另一个角度去理解，这就是一个在16位的实模式下另类的虚拟磁盘而已。

为何想到要用原始办法来开发类似Storport框架的虚拟磁盘驱动？估计是闲的蛋疼吧。又或者为了彰显曾经无法理解和实现的，现在具备了一定基础，再来实现，却发现变得异常的简单。记得以前开发winxp下的Scsiport框架的虚拟磁盘驱动，非常的麻烦，不但要解决虚拟模拟部分，安装驱动电脑还得重启好几次才能安装成功。