geom(4): Look for aliases when searching for providers by name

[cem]

Test Plan

# geli attach /dev/gpt/testingeli
Enter passphrase:
GEOM_ELI: Device md0s1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: software
GEOM_LABEL[2]: Tasting md0s1.eli.

# ls -l /dev/gpt/testingeli*
lrwxr-xr-x 1 root wheel  8 Jun  6 09:22 /dev/gpt/testingeli -> ../md0s1
lrwxr-xr-x 1 root wheel 12 Jun  6 09:24 /dev/gpt/testingeli.eli -> ../md0s1.eli

[cem]

I took this approach because many geom_*_ctl consumers use this API to locate /dev/foo names. Another option would be to do realpath in userspace, but this seems more robust to me, and in the spirit of having provider aliases.

Does this approach make sense to you? Thanks.

sys/geom/geom_subr.c

783–786

The 'continue' case should skip this provider IFF the provider name does not match arg AND no alias of the provider matches arg.

[delphij]

Were you able to find out why GPT partitions are not showing up in the /dev/diskid directory (e.g. /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4p2), or are you not seeing similar behavior (since it might be specific to my usage, details in Message-ID: <[e-mail]>)?

[cem]

In D25168#561683, @delphij wrote:

Were you able to find out why GPT partitions are not showing up in the /dev/diskid directory (e.g. /dev/diskid/DISK-BHYVE-2613-8EFD-BAF4p2), or are you not seeing similar behavior (since it might be specific to my usage, details in Message-ID: <[e-mail]>)?

I was able to reproduce the problem in a VM, but did not discover why partition aliases were not being created on /dev/diskid entries.

[delphij]

It seems that the lack of /dev/diskid nodes was not a regression so it's not a blocker.

However this patch is incomplete as some GEOM classes are not using g_provider_by_name (see the variant of this revision in https://github.com/delphij/freebsd/commits/scratch/geom ). I think a better way of doing this would be to refactor the lookup routines out.

On an unrelated note -- @mav I noticed that you have added the prefer non-withered providers logic in rS280685 but it's not obvious to me why we want to return an withered provider in g_provider_by_name(). Do you still remember the scenario that this would be useful for the caller?

[mav]

In D25168#566279, @delphij wrote:

On an unrelated note -- @mav I noticed that you have added the prefer non-withered providers logic in rS280685 but it's not obvious to me why we want to return an withered provider in g_provider_by_name(). Do you still remember the scenario that this would be useful for the caller?

I don't remember what cause I had for it in g_provider_by_name(), may be just wanted to be safe, but I do see it convenient and right to be able to see withered providers and geoms in the command line tools. They may stay like this for a long time if consumer haven't closed them, and the tools help with debugging.

[mav]

I haven't looked much on aliases, but this looks good to me.