mmccam: fix mmcsd disk aliases

[bz]

Summary

For EXT_CSD_PART_CONFIG_ACC_BOOT<n> and possibly others with suffixes
we fail to create proper disk aliases (symlinks), which shows up as
g_dev_taste: make_dev_alias_p() failed (name=mmcsd0, error=17)

In this case we ended up with the followng two:

/dev/mmcsd0 -> sdda0
/dev/mmcsd1 -> sdda0boot1

Note that (i) it should be mmcsd0boot1 and not mmcsd1 and that
(ii) there is no mmcsd0boot0 (failed above as it tried to create a
second mmcsd0).

While in theory we do not need to handle all cases for the compat
scheme add the code for all of them.

This gives us:

/dev/mmcsd0 -> sdda0
/dev/mmcsd0boot0 -> sdda0boot0
/dev/mmcsd0boot1 -> sdda0boot1

MFC after: 3 days

[imp]

sys/cam/mmc/mmc_da.c

1596

I'd jusr kill this. We are three major releases past this, no?

1622

Panic?

[imp]

sys/cam/mmc/mmc_da.c

1596

Oh, wait, sorry, ignore this comment. It's wrong....

1625

While this is fine, since it's unlikely that we'll have new part config types, it does repeat the code from the nonCAM MMC stack.

[imp]

Though if we defined SDDA_FMT as %s%dfoo instead of sdda%dfoo, we could just do a second snprintf and not need the case statement with panic in it, with an adjustment to the first snprintf of course.

[bz]

Implement the suggestion from @imp to use a double fmt string for "name" and "unit".

The implementation is indeed a lot simpler.

I left an extra comment given for the "sdda"<n> entry we do ignore the <n> given
to the snprintf anyway (and nothing complains about an extra argument to a fmt
string not consuming it?).

With this I see no warnings and get something like this:

ls -l /dev/sdda* /dev/mmcsd*

lrwxr-xr-x 1 root wheel 5 Jan 1 00:00 /dev/mmcsd0 -> sdda0
lrwxr-xr-x 1 root wheel 5 Jan 1 00:00 /dev/mmcsd1 -> sdda1
lrwxr-xr-x 1 root wheel 10 Jan 1 00:00 /dev/mmcsd1boot0 -> sdda1boot0
lrwxr-xr-x 1 root wheel 10 Jan 1 00:00 /dev/mmcsd1boot1 -> sdda1boot1
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p1 -> sdda1p1
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p2 -> sdda1p2
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p3 -> sdda1p3
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p4 -> sdda1p4
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p5 -> sdda1p5
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p6 -> sdda1p6
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p7 -> sdda1p7
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p8 -> sdda1p8
lrwxr-xr-x 1 root wheel 7 Jan 1 00:00 /dev/mmcsd1p9 -> sdda1p9
crw-r----- 1 root operator 0x5a Jan 1 00:00 /dev/sdda0
crw-r----- 1 root operator 0x5d Jan 1 00:00 /dev/sdda1
crw-r----- 1 root operator 0x5f Jan 1 00:00 /dev/sdda1boot0
crw-r----- 1 root operator 0x61 Jan 1 00:00 /dev/sdda1boot1
crw-r----- 1 root operator 0x63 Jan 1 00:00 /dev/sdda1p1
crw-r----- 1 root operator 0x65 Jan 1 00:00 /dev/sdda1p2
crw-r----- 1 root operator 0x67 Jan 1 00:00 /dev/sdda1p3
crw-r----- 1 root operator 0x69 Jan 1 00:00 /dev/sdda1p4
crw-r----- 1 root operator 0x6b Jan 1 00:00 /dev/sdda1p5
crw-r----- 1 root operator 0x6d Jan 1 00:00 /dev/sdda1p6
crw-r----- 1 root operator 0x6f Jan 1 00:00 /dev/sdda1p7
crw-r----- 1 root operator 0x71 Jan 1 00:00 /dev/sdda1p8
crw-r----- 1 root operator 0x73 Jan 1 00:00 /dev/sdda1p9

[imp]

POSIX and the ISO C standard both say
"If the format is exhausted while arguments remain, the excess arguments shall be evaluated but are otherwise ignored."
So

printf("%s\n", "fred", foo(12));

is legal, and foo is called with the argument 12, but then is ignored.

The other way (too many format specifiers for the args passed) results in UB.