History log of /freebsd-head/usr.bin/mkimg/vhd.c
Revision Date Author Comments
1cceceb8e256cc06c9697066cd42540b588287e7 06-Jan-2019 delphij <delphij@FreeBSD.org> Remove unneeded headers.

MFC after: 1 month
a31300a1ec00c0d5b95ebc0cd0d59818668fabc4 18-Oct-2016 marcel <marcel@FreeBSD.org> o Provide a private definition for UUIDs (mkimg_uuid_t) because
UUIDs are not portable.
o Move mkimg_uuid() to a new file and merge both gpt_uuid_enc()
and vhd_uuid_enc() into a single mkimg_uuid_enc() that lives
in the same file.
o Move the OS-specific implementation of generating a UUID to
osdep_uuidgen() and provide the implementations for FreeBSD,
macOS and Linux.
o Expect the partitioning scheme headers to be found by having
a search to the directory in which the headers live. This
avoids conflicts on non-FreeBSD machines.
5e84416ac964829fd8974acdd790791ef1d2aa7e 03-Oct-2016 marcel <marcel@FreeBSD.org> Prefer <stdint.h> over <sys/types.h>. While here remove redundant
inclusion of <sys/queue.h>.

Move the inclusion of the disk partitioning headers out of order
and inbetween standard headers and local header. They will change
in a subsequent commit.
741bf1228e837b7eb7ffbfe84f3c9544c0246ffe 26-Sep-2016 marcel <marcel@FreeBSD.org> Avoid depending on the <sys/endian.h> header for le*enc and be*enc.
Not only is the header unportable, the encoding/decoding functions
are as well. Instead, duplicate the handful of small inlines we
need into a private header called endian.h.

Aside: an alternative approach is to move the encoding/decoding
functions to a separate system header. While the header is still
nonportable, such an approach would make it possible to re-use the
definitions by playing games with include paths. This may be the
preferred approach if more (build) utilities need this. This
change does not preclude that. In fact, it makes it easier.
00d578928eca75be320b36d37543a7e2a4f9fbdb 27-May-2016 grehan <grehan@FreeBSD.org> Create branch for bhyve graphics import.
d53cfebe2f15ceb38c2d4e7897391b81ca63387c 25-Aug-2015 marcel <marcel@FreeBSD.org> MFC r286660, r286419, r286417, r286395, r286215, r284883

- Add the ntfs alias
- Fix the dynamic VHD format to work with qemu
- Update manpage

Differential Revision:
c071cf56f2033188df3f7448009d6b2b5d3bba0a 07-Aug-2015 marcel <marcel@FreeBSD.org> Fix the dynamic VHD format to work with qemu. The size of the disk
is taken to match the geometry and only when the geometry is max'd
out, is the actual recorded size taken.

Note that qemu has the same logic for the fixed VHD format. However
that is known to conflict with Microsoft Azure, where the recorded
size of the image is what counts.

Pointed out by: gjb@
c8b4a5d462f81bded2f88253a2feb3abc492b84a 24-Jun-2015 marcel <marcel@FreeBSD.org> MFC r284269, r284270, r284655, r284656, r284658:
VHD fixes for Microsoft Azure:
1. Round the image size to the VHD geometry and then round to a
multiple of 1MB.
2. Change the creator OS from "FBSD" to "Wi2k". It matters...
3. Bump the VHD tool version and the mkimg version.

Approved by: re (gjb)
dd8725551fcdb961ab8ae8697637159722dae6d0 21-Jun-2015 marcel <marcel@FreeBSD.org> Microsoft Azure expects the creator OS to be "Wi2k" and not "FBSD".
The image is not accepted for provisioning otherwise. Bump the
VHD creator tool version and the version of mkimg to signify our
success in provisioning.

Note that this also imapcts the dynamic VHD images.

Tested by: gjb@
149795a98acb288cb2bf7a8a85110373a8df845f 21-Jun-2015 marcel <marcel@FreeBSD.org> Microsoft Azure demands that fixed VHD images are a whole number
of megabytes. This is on top of having the image rounded to the
matching geometry of the image size.
By rounding up to the next MB after rounding to the geometry, we
lost idempotency. Subsequent calls to resize the image will keep
increasing the image size.

Tested by: gjb@
d7cd5ce73af6485320dfb339743ee5a1b1d77f09 11-Jun-2015 marcel <marcel@FreeBSD.org> Handle the case in which ncyls is 0.
While here, update copyright.
7577833480685b0e8e3569ee18ebc6fcc6292adb 11-Jun-2015 marcel <marcel@FreeBSD.org> For the fixed VHD format, round the raw image size to the next
multiple of the cylinder size. This is what qemu-img seems to
be doing. Make sure to handle boundary cases where increasing
the image size by 1 cyclinder's worth would also result in a
change of geometry.
a74e992d46af3caf22eae106b9627987fb1d6468 01-Oct-2014 marcel <marcel@FreeBSD.org> Suffix the cookie constants with ULL to silence warnings from compilers
that try to treat them as 32-bit values.
2dfd8b7dad7fa05a1ffc164eeb14e3847bba8fd0 29-Jul-2014 pluknet <pluknet@FreeBSD.org> MFC r268727 (by delphij):

Add a bandaid to fix GCC build (on sparc64 et al).
37a9f7be2fd32cf24c75d466cacac9ce83a3766b 28-Jul-2014 marcel <marcel@FreeBSD.org> MFC r268236,268264,268524,268646,268802,269021:
This brings VHD support to mkimg(1); both dynamic and fixed file formats.
Dynamic VHD and VMDK file images are now sparsely written, meaning that
"free" sectors do not occupy space.

Relnotes: yes
b85c67749726e5e17e5591899188cc8d1f5c9a9d 23-Jul-2014 marcel <marcel@FreeBSD.org> Fix builds on older FreeBSD versions and/or non-FreeBSD machines:
don't use _Static_assert unconditionally.
9e7978627486d0930f2b15c1843a1f9239a0e517 17-Jul-2014 marcel <marcel@FreeBSD.org> Add support for the fixed image type. The fixed image is effectively
a raw image with a VHD footer appended. There's little value that I
can see to use the fixed image type, but in order to make VHD images
for use by Microsoft's Azure platform, they must be fixed VHD images.

Support has been added by refactoring the code to re-use common code
and by adding a second output format structure. To created fixed VHD
images, specify "vhdf" as the output format.
7da6d95166c02118f3aa4c890ea2e23a306f31fb 15-Jul-2014 delphij <delphij@FreeBSD.org> Add a bandaid to fix GCC build (on sparc64 et al).
ca1d5922c55b13221ec863517dce4d9329318a56 15-Jul-2014 marcel <marcel@FreeBSD.org> Add image_data() for checking whether a sequence of blocks has data.
Use this for VHD and VMDK to avoid allocating space in the image
for empty sectors.

Note that this negatively affects performance because mkimg uses a
temporary file for the intermediate storage. When mkimg has better
internal book keeping, performance can be significantly improved.