History log of /dragonfly/sys/sys/disklabel64.h (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc
# 0a319615 10-Mar-2018 Matthew Dillon <dillon@apollo.backplane.com>

disklabel64 - Make disktype optional, fix alignment bug

* Make the disktype optional, use 'auto' automatically

* Fix a bug in the kernel's l64_makevirginlabel() calculation.
It was not properly c

disklabel64 - Make disktype optional, fix alignment bug

* Make the disktype optional, use 'auto' automatically

* Fix a bug in the kernel's l64_makevirginlabel() calculation.
It was not properly calculating the alignment relative to
the physical disk.

* Refactor some of the documentation

* Refactor examples

Submitted-by: Aaron LI <aly@aaronly.me>

show more ...


Revision tags: v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1, v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0, v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3, v3.0.2, v3.0.1, v3.1.0, v3.0.0
# 86d7f5d3 26-Nov-2011 John Marino <draco@marino.st>

Initial import of binutils 2.22 on the new vendor branch

Future versions of binutils will also reside on this branch rather
than continuing to create new binutils branches for each new version.


Revision tags: v2.12.0, v2.13.0, v2.10.1, v2.11.0, v2.10.0, v2.9.1, v2.8.2, v2.8.1, v2.8.0, v2.9.0, v2.6.3, v2.7.3, v2.6.2, v2.7.2, v2.7.1, v2.6.1, v2.7.0, v2.6.0, v2.5.1, v2.4.1, v2.5.0, v2.4.0, v2.3.2, v2.3.1, v2.2.1, v2.2.0, v2.3.0, v2.1.1, v2.0.1
# eb484664 19-Jun-2007 Matthew Dillon <dillon@dragonflybsd.org>

Rename d_obj_uuid to d_stor_uuid to conform to the naming convention being
used in other structures.


# 18cb7add 19-Jun-2007 Matthew Dillon <dillon@dragonflybsd.org>

Make some adjustments to clean up structural field names. Add type and
storage uuid's to the partinfo structure for the DIOCGPART ioctl and
load the fields up for GPT slices and disklabel64 partitio

Make some adjustments to clean up structural field names. Add type and
storage uuid's to the partinfo structure for the DIOCGPART ioctl and
load the fields up for GPT slices and disklabel64 partitions.

show more ...


# 0ffe40b3 19-Jun-2007 Matthew Dillon <dillon@dragonflybsd.org>

Implement non-booting support for the DragonFly 64 bit disklabel:

* Add full kernel support. Both 32 and 64 bit labels will be probed.
* Add a new program, disklabel64, which allows you to create a

Implement non-booting support for the DragonFly 64 bit disklabel:

* Add full kernel support. Both 32 and 64 bit labels will be probed.
* Add a new program, disklabel64, which allows you to create and edit
the new disklabel.
* Add some logic to prevent foot shooting.

DragonFly's 64 bit disklabels start at byte offset 0 on the disk slice
or GPT partition and operate in a slice-relative fashion. No translation
is required when going from on-disk to in-core or vise-versa, unlike the
existing 32 bit disklabels. 512 bytes at the beginning of the label are
reserved for legacy boot code. Specifically, the label starts at sector 0,
NOT sector 1, which means its location on the disk is the same regardless
of the sector size.

The label has a UUID to uniquely identify the storage and a type and
object uuid for each partition. All location specifications are 64 bit
byte offsets, NOT logical blocks. The label enforces an alignment
requirement for label-related I/O and partitions which defaults to 4K
regardless of the sector size. This makes the label 100% portable across
media with different sector sizes within the constraints of the alignment
requirement.

All partitions are specified using byte offsets and sizes, constrained
by the alignment requirement, relative to the base of the label (i.e.
offset 0 in the slice). disklabel64 will adjust the offsets for display
purposes to be relative to the partition table area. The label headers,
partition table, and boot2 areas come BEFORE the partition table area and
partitions which overlap any of those objects are not allowed.

By default, a virgin 64 bit disklabel will reserve 32K for boot2. As of
this writing, boot1 and boot2 blocks have not yet been implemented.

show more ...


# 2b961883 18-Jun-2007 Matthew Dillon <dillon@dragonflybsd.org>

Move all the code related to handling the current 32 bit disklabel
to subr_disklabel32.c. Move the header file from sys/disklabel.h to
sys/disklabel32.h. Rename all the related structures and const

Move all the code related to handling the current 32 bit disklabel
to subr_disklabel32.c. Move the header file from sys/disklabel.h to
sys/disklabel32.h. Rename all the related structures and constants
and retire 'struct disklabel'.

Redo the sys/disklabel.h header file to implement a generic disklabel
abstraction. Modify kern/subr_diskslice.c to use this abstraction, with
some shims for the ops dispatch at the moment which will be cleaned up later.

Adjust all auxillary code that directly accesses 32 bit disklabels to use
the new structure and constant names.

Remove the snoop-adjust code. The kernel would snoop reads and writes to
the disklabel area via the raw slice device (e.g. ad0s1) and convert the
disklabel from the in-core format to the on-disk format and vise-versa.
The reads and writes made by disklabel -r and the kernel's own internal
readdisklabel and writedisklabel code used the snooping.

Rearrange the kernel's internal code to manually convert the disklabel when
reading and writing. Rearrange the /sbin/disklabel program to do the same
when the -r option is used. Have the disklabel program also check which
DragonFly OS it is running under so it can be run on older systems. Note
that the disklabel binary prior to these changes will NOT operate on the
disklabel properly if running on a NEW kernel.

Introduce skeleton files for 64 bit disklabel support.

show more ...