On Mon, Jun 18, 2018 at 09:52:43PM +0000, Harry Mallon wrote:
> However, APFS is not really a filesystem type, but includes a volume
> manager too. Perhaps recognition of the partition type is not
> complete enough for upstream?
Arbitrary Apple APFS detection will be improvement. So, detect magic
string and nothing else is good start.
> I am looking at making an
> implementation in the partitions folder rather than the superblocks
> folder (inspired by code in the reverse engineered apfs-fuse driver)
> to enumerate and fill in the volumes listed but this is an order of
> magnitude more code to work with.
I prefer libblkid/src/superblocks folder if we're not able to read
"slices" (partitions, root, etc) from the device. The same situation
is for example ZFS or BTRFS.
> Would a pure recognition-only apfs module be of interest?
Sure.
> Does anyone have any tips on writing a partition table reader version?
I have doubts about it as nothing about the internal logic is public
and it's crazy to provide write access or map internal APFS stuff to
real Linux block devices if we're not sure how... sounds to dangerous.
> Is libblkid the right place for this code or is there some other layer I should be looking at?
libblkid is the right place for detection
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
