|
本帖最后由 longpanda 于 2021-12-26 23:02 编辑
你理解的基本上都是对的。
Ventoy的最基本的原理就是 INT13中继(legacy) 和Block IO protocol 中继(UEFI) 其实就是虚拟了一个CDROM
在Legacy模式下memdisk以及grub4dos的map等,都属于这种int13 hook技术,但是都有限制,memdisk需要把文件load到内存,
但是对于大镜像是行不通的, grub4dos的map需要文件在磁盘连续存放,也是有限制的。(更新: 最新版本grub4dos的map支持文件碎片,但是好像对于碎片数有限制。)
ventoy在这个地方做了一点优化。里面首先通过grub2的FS模块解析出ISO文件在磁盘中的所有块的位置,然后在hook INT13的时候做了中转处理。
Legacy模式下的INT13 hook是在IPXE模块做的,是以IPXE的sanboot为基础,增加了 int13 中转的实现。
UEFI模式差不多,只是不用int13而是Block IO Protocol,原理是一样的。
Linux镜像插入init进程确实如你所说,因为很多Linux当前版本不支持exFAT挂载,所以要插入一些处理。但是这个插入也是做了一些创新。
并不需要把initrd都读入内存,而是直接从ISO 9660文件格式的层面插入,所以能保留原始ISO文件的启动菜单。
Windows也是一样,插入的实现也是从UDF文件格式层面进行的,不像wimboot那样需要把wim文件读到内存中。对于ISO的挂载,Windows 8+的版本是通过Win32 VirutalDisk API实现的,Window7是借助imdisk挂载。
所以,Ventoy启动时你可以感觉到一下子就出来原始ISO文件的启动菜单了。就是因为不需要把几十M的initrd或者上百M的 boot.wim文件先读到内存的原因。
另外,插入init以及Windows挂载ISO的过程实际上都不是Ventoy想做的,只是不得已。所以我提出了一个 “Ventoy Compatible”的概念,就是想让ISO里面兼容Ventoy,而不是我来hook, Ventoy提供了工具,在系统中可以获取到当前是不是从Ventoy虚拟的这个CDROM中启动的,以及是从哪个磁盘上的哪个ISO文件启动的,这样就可以继续进行下去,而不会因为找不到安装介质而停止了。如果ISO内部能这样,对于Ventoy就简单了,只需要专心做好这个虚拟CDROM就好了。Ventoy 60%以上的精力都花在了hook上面了,尤其是千奇百怪的Linux发行版。
你说的读条的过程,我本地测试是有的,不知道你这边为什么没有。
Aoe的代码纯粹是为了支持TinyLinux这个发行版,它里面啥都没有,device mapper, FUSE, NBD都没有,只有一个AOE驱动,所以加了这个部分。
那部分看不懂的代码,我能说是我放的一个彩蛋吗:),哈哈,是不是比较无聊
|
评分
-
查看全部评分
|