| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
MFC after: 1 month
Notes:
svn path=/head/; revision=342813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=307544
|
|
|
|
| |
Notes:
svn path=/head/; revision=307387
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=306621
|
|
|
|
|
|
|
|
|
|
|
| |
be used on both macOS and Linux. STAILQs are not. In particular,
STAILQ_LAST does not next on Linux. Since neither STAILQ_FOREACH_SAFE
nor TAILQ_FOREACH_SAFE exist on Linux, replace its use with a regular
TAILQ_FOREACH. The _SAFE variant was only used for having the next
pointer in a local variable.
Notes:
svn path=/head/; revision=306620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=306330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-T (track size) or -H (number of heads) is given:
o scheme_metadata() always rounded to the block size. This is not
always valid (e.g. vtoc8 that must have partitions start at cylinder
boundaries).
o The bsd and vtoc8 schemes "resized" the image to make it match the
geometry, but since the geometry is an approximation and the size
of the image computed from cylinders * heads * sectors is always
smaller than the original image size, the partition information ran
out of bounds.
The fix is to have scheme_metadata() simply pass it's arguments to the
per-scheme metadata callback, so that schemes not only know where the
metadata is to go, but also what the current block address is. It's now
up to the per-scheme callback to reserve room for metadata and to make
sure alignment and rounding is applied.
The BSD scheme now has the most elaborate alignment and rounding. Just
to make the point: partitions are aligned on block boundaries, but the
image is rounded to the next cyclinder boundary.
vtoc8 now properly has all partitions aligned (and rounded) to the
cyclinder boundary.
Obtained from: Juniper Networks, Inc.
MFC after: 3 days
Notes:
svn path=/head/; revision=271881
|
|
|
|
|
|
|
|
| |
before multiplying the 32-bit integrals to avoid any possibility of
truncation before widening. Not a likely scenario to begin with...
Notes:
svn path=/head/; revision=266514
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for different output formats:
1. The output file that was previously written is now called the raw format.
2. Add the vmdk output format to create VMDK images.
When the format is not given, the raw output format is assumed.
Notes:
svn path=/head/; revision=266176
|
|
|
|
|
|
|
|
|
|
|
| |
sector granularity for both offset and length. Have all schemes
use mkimg_write() instead of mkimg_seek() followed by write(2).
Now that schemes don't use lseek(2) nor write(2) directly, it's
easier to support output formats other than raw disks.
Notes:
svn path=/head/; revision=265468
|
|
|
|
| |
Notes:
svn path=/head/; revision=263924
|
|
The partitioning scheme can be one of the schemes supported by gpart.
Reviewed by: sjg
Obtained from: Juniper Networks, Inc.
Notes:
svn path=/head/; revision=263918
|