Move disk scheme definitions under <sys/disk/$scheme.h>

[marcel]

Summary

In order to allow mkimg(1) (and other tools) to become a build tool that can be compiled on various OSes (including on older versions of FreeBSD), make it possible to have them include the scheme definitions without pulling in FreeBSD specific definitions. In particular this means:

• moving the portable scheme definitions to header files under sys/disk
• not including other system headers
• replacing u_int*_t with uint*_t throughout.

Since UUID/GUID type definitions are non-portable, make it possible to use any (valid) type by setting GPT_UUID_TYPE to the type used on the build machine. When GPT_UUID_TYPE hasn't been defined, use "union gpt_uuid" as a generic substitute.

More consistently have the BSD scheme use the BSD_ prefix for defines. There should be no conflict between the headers, making it possible to include them all in the same file

note: consumers of the old headers have not been changed yet. Such will be done in followup commits

Test Plan

No functional change
make universe passes

[marcel]

Fixes to the previous diff:
o Have the generic GPT uuid definition match the UUID constants so that the header is self-consistent and usable without "external" definition for UUIDs.
o Typedef gpt_uuid_t from GPT_UUID_TYPE to make it more palatable for applications to use the GPT type for UUIDs themselves.
o Fix a comment in sys/sys/disklabel.h

[imp]

generally I like it, though it fills me with fear and dread since it's the oldest part of the system and has been the most fragile. That risk is mitigated by a 'universe' run as well as a exp-ports run.

sys/sys/disklabel.h

53

Historically the transport has been a problem. These constants existed to co-exist with the host's native labels. Alpha was the last one FreeBSD had where it mattered. OpenBSD's labels are also a different size because it doesn't have GEOM and had to do all manner of ugly kludges.

[jhb]

Definitely a fan of the approach generally. I have a minor preference for <disk/foo.h> vs <sys/disk/foo.h> as there is nothing kernel-specific about these at all. I think it would be fine in that case to have a new top-level directory in sys for just these headers if it came to it. However, that isn't a show stopper. I think the GPT_UUID_TYPE thing is ok.

[marcel]

Committed