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 ...
|