Add string16 API

[eric_metricspace.net]

Summary

This patch adds the string16 API used in the larger changeset https://reviews.freebsd.org/D7589. This is a component of that patch.

Test Plan

This should be a behavior-neutral changeset. It can be tested simply by boot-testing boot1.efi and loader.efi.

[imp]

All the string functions suffer from the same problem we have with the original string functions you replaced: they don't properly implement character conversions. Please see the efivar stuff I did in -current to see what you need to do there. And you should put the functions I wrote there into libstand. While these functions work well enough for ASCIIish things, they fail for anything more complex. If we're going to rework things, let's do it correctly and reuse what was done correctly for efivar (who, to be fair, stole and reworked the code from Marcel's earlier efi on ia64 work).

[tsoome]

In D9687#200246, @imp wrote:

All the string functions suffer from the same problem we have with the original string functions you replaced: they don't properly implement character conversions. Please see the efivar stuff I did in -current to see what you need to do there. And you should put the functions I wrote there into libstand. While these functions work well enough for ASCIIish things, they fail for anything more complex. If we're going to rework things, let's do it correctly and reuse what was done correctly for efivar (who, to be fair, stole and reworked the code from Marcel's earlier efi on ia64 work).

I have additional question... how much the naming is reflected to anything "standard", I mean, sure, the new names do reflect a bit better what is supposed to happen, but could it be we will find ourselves renaming them once again?:)

[eric_metricspace.net]

In D9687#200246, @imp wrote:

All the string functions suffer from the same problem we have with the original string functions you replaced: they don't properly implement character conversions. Please see the efivar stuff I did in -current to see what you need to do there. And you should put the functions I wrote there into libstand. While these functions work well enough for ASCIIish things, they fail for anything more complex. If we're going to rework things, let's do it correctly and reuse what was done correctly for efivar (who, to be fair, stole and reworked the code from Marcel's earlier efi on ia64 work).

Agreed that libstand is probably the right place for all this. The point of me introducing these was to try to standardize things better. If there's already code that does it better, then I should use that instead.

Can you link to the changeset that introduced the efivar stuff (for the sake of other reviewers as well)?

[imp]

Can you link to the changeset that introduced the efivar stuff (for the sake of other reviewers as well)?

https://svnweb.freebsd.org/base/head/lib/libefivar?revision=307071&view=markup is a good place to start. There were followup commits.

[eric_metricspace.net]

I like the interface in lib/libefi/libefi.c

What about CHAR16 vs u_short? Should this really go into libstand, or would it be more appropriate to put it in lib/libefi and add a dependency to boot/efi/libefi?