|
From: Anton A. <ai...@ca...> - 2012-07-21 20:07:32
|
Hi, One further thought. If we go down the route of allowing access to other partitions followed by access to LDM partitions in the same namespace, just with higher numbers then perhaps we should also add the LDM database partition as an exposed device. It would make it much easier for an LDM userspace tool to work with it if it could simply be pointed at the LDM database by specifying it is on /dev/hdaN or something... What do you think? Best regards, Anton On 21 Jul 2012, at 09:47, Anton Altaparmakov wrote: > Hi, > > On 21 Jul 2012, at 09:30, Anton Altaparmakov wrote: >> On 21 Jul 2012, at 03:24, Carl-Daniel Hailfinger wrote: >>> There is also the question of naming the devices... hiding all GPT >>> partitions is a bit inconvenient if someone wants to access the GPT BIOS >>> Boot Partition or the GPT EFI System Partition (e.g. for installing a >>> bootloader). Device names like hdXldmN (hdaldm1) instead of hdXN (hda1) >>> are really clumsy, but I don't have a better suggestion. >> >> Not really. I doubt you would ever have a GPT BIOS partition or a GPT EFI System partition on a Windows Dynamic Disk. The only partitions are the LDM database partition, the Microsoft reserved partition, and the LDM data partition which covers the entire disk (except for the little bits occupied by the LDM database partition and MS reserved partition). So I don't think this is an issue as there will be no other partitions that you would want to expose. > > > Hm. I was wrong. (-; > > Just googled this incredibly useful FAQ from Microsoft: > > http://msdn.microsoft.com/en-us/library/windows/hardware/gg463525.aspx > > It explains bootable dynamic disks. Fortunately it explains that the EFI system partition (ESP) must be the first partition and same for any other non-LDM partitions. So my example code needs changing so that it allows "efi.c" normal code to work (i.e. call put_partition(), etc) UNTIL an LDM database partition is found at which point it should switch to LDM handling and if that fails it should retry with pure GPT but only starting at the LDM database partition as the others are already done. > > And the LDM database partition detection needs to change to no longer insist on "i" being zero as that clearly doesn't need to be the case. > > So I think there is no need to change the names. We just have hdX1, 2, 3, 4, etc. where 1 is the ESP, 2..N are other partitions, N+1 is the first LDM partition, etc. I think that works well. So it treats LDM partitions effectively like extended partitions on MBR. What do you think? I think it is neater than having to do hdXldmY... > > Best regards, > > Anton > -- > Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) > Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK > Linux NTFS maintainer, http://www.linux-ntfs.org/ > Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ |
