Working on my own filesystem (OpenZFS) and I need to go back and address the issue with EFI partitions. When looking at a disk from one of the other platforms (illumos, linux, osx, freebsd) the ZFS pool disks have a normal MBR partition protecting the EFI label. So with Windows, using the API like IOCTL_DISK_GET_DRIVE_LAYOUT_EX, all I get is the gpt partition, and hence, PHYSICALDRIVE1 and that is it.
In my code I call libefi to read the EFI partition, looks like:
At the moment, I hack that up and pass the device name to the kernel as "#partition-offset#partition-length#\\?\PHYSICALDRIVE0".
Code: Select all
'\\?\PhysicalDrive0' IOCTL_DISK_GET_DRIVE_LAYOUT_EX read partitions ok 2 gpt 0: type 8f7ee1d0 off 0x100000 len 0x13f600000 gpt 1: type 8f7ee1d0 off 0x13f700000 len 0x800000 asking libefi to read label EFI read OK, max partitions 9 part 0: offset 800: len 9fb000: tag: 4 name: 'zfs' part 1: offset 9fb800: len 4000: tag: b name: ''
So it is time to fix that. I think it would be nice if I could call FindFirstVolume() / FindNextVolume(), and the 'zfs' partition would be one of them.
So, it is my guess (!) that I should write a driver that, using libefi, on any (unclaimed?) PHYSICALDRIVE and if I am able to read an EFI partitition of type 'zfs' (well, I guess proper code would support all partition types, but I only need zfs for now). create a virtual disk (somehow) and create a symlink like "PhysicalDrive0Partition1" or whatever the notation is. Then simply relay IO, making sure to offset the partition start?
Is that the best idea? Are there examples that mostly do this already? What would you do if you had to solve this?