> This commit is really hard to follow. I wonder if it can be broken up
> to make it easier to review. There seem to be at least two parts to
> the patch: (1) Changing the way that we detect if a device contains
> partitions. (2) Changing the way that we filter out LDM partitions.

Agree. Splitted this commit to a series of more granular commits.

> "check_device", "check_partition" are really generic names. Name the
> functions according to what they do, eg. "is_not_partitioned_device".

Agree.

> > +and is_ignored_gpt_type gpt_type =
> > + match gpt_type with
>
> You can write this as:
>
> and is_ignored_gpt_type = function
> | pattern -> result
> | ...

I've got rid of separate function at all.

> > + (* Windows Logical Disk Manager metadata partition. *)
> > + | "5808C8AA-7E8F-42E0-85D2-E1E90434CFB3" -> Optgroups.ldm_available ()
> > + (* Windows Logical Disk Manager data partition. *)
> > + | "AF9B60A0-1431-4F62-BC68-3311714A69AD" -> Optgroups.ldm_available ()
>
> Why does the result depend on Optgroups.ldm_available ()?

Yes, it shouldn't.

> > + (* Microsoft Reserved Partition. *)
> > + | "E3C9E316-0B5C-4DB8-817D-F92DF00215AE" -> true
> > + (* Windows Snapshot Partition. *)
> > + | "CADDEBF1-4400-4DE8-B103-12117DCF3CCF" -> true
>
> You can combine the right hand sides of multiple matches, which helps
> the pattern match optimizer in the compiler, eg:
>
> (* Microsoft Reserved Partition. *)
> | "E3C9E316-0B5C-4DB8-817D-F92DF00215AE"
> (* Windows Snapshot Partition. *)
> | "CADDEBF1-4400-4DE8-B103-12117DCF3CCF" -> true
> | _ -> false

Ah, thanks.

> Catching the generic exception is usually a big red flag. What
> exceptions are you expecting here? If you're not expecting an
> exception, don't try to catch anything.

Agree. There is no expected exceptions there.

I thought: If something went wrong - let's not filter out device or partition.

v6 is coming.

Mykola Ivanets