History log of /src/lib/geom/label/Makefile (Results 1 – 13 of 13)
Revision Date Author Comments
# 18b226ea 11-Oct-2024 Robert Clausecker <fuz@FreeBSD.org>

lib/geom: remove redundant libraries and objects

Do not link lib/geom/raid with libmd, it is not required for the module.
Do not include the sha256/sha512 code in lib/geom/eli, it is provided by
lib

lib/geom: remove redundant libraries and objects

Do not link lib/geom/raid with libmd, it is not required for the module.
Do not include the sha256/sha512 code in lib/geom/eli, it is provided by
libmd. Remove ${.CURDIR:H:H}/misc from .PATH for all modules. This
path has stopped being valid when the GEOM modules were moved from
sbin/geom to lib/geom.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47061

show more ...


# e9ac4169 15-Jul-2024 Warner Losh <imp@FreeBSD.org>

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix


# d0b2dbfa 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/


# 0bf68878 22-Jul-2022 Emmanuel Vadot <manu@FreeBSD.org>

pkgbase: Put geom utilities in their own package

For most users it's not needed to boot and they are also
available in the FreeBSD-rescue package in case an update
break and FreeBSD-geom package isn

pkgbase: Put geom utilities in their own package

For most users it's not needed to boot and they are also
available in the FreeBSD-rescue package in case an update
break and FreeBSD-geom package isn't updated correctly.

Differential Revision: https://reviews.freebsd.org/D36224

show more ...


# 18b226ea 11-Oct-2024 Robert Clausecker <fuz@FreeBSD.org>

lib/geom: remove redundant libraries and objects

Do not link lib/geom/raid with libmd, it is not required for the module.
Do not include the sha256/sha512 code in lib/geom/eli, it is provided by
lib

lib/geom: remove redundant libraries and objects

Do not link lib/geom/raid with libmd, it is not required for the module.
Do not include the sha256/sha512 code in lib/geom/eli, it is provided by
libmd. Remove ${.CURDIR:H:H}/misc from .PATH for all modules. This
path has stopped being valid when the GEOM modules were moved from
sbin/geom to lib/geom.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47061

show more ...


# e9ac4169 15-Jul-2024 Warner Losh <imp@FreeBSD.org>

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix


# d0b2dbfa 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/


# 0bf68878 22-Jul-2022 Emmanuel Vadot <manu@FreeBSD.org>

pkgbase: Put geom utilities in their own package

For most users it's not needed to boot and they are also
available in the FreeBSD-rescue package in case an update
break and FreeBSD-geom package isn

pkgbase: Put geom utilities in their own package

For most users it's not needed to boot and they are also
available in the FreeBSD-rescue package in case an update
break and FreeBSD-geom package isn't updated correctly.

Differential Revision: https://reviews.freebsd.org/D36224

show more ...


# e4b0a90e 25-Jun-2018 Brooks Davis <brooks@FreeBSD.org>

Normalize the g(eom,cache,part,...) build.

Rather then combining hardlink creation for the geom(8) binary with
shared library build, move libraries to src/lib/geom so they are
built and installed no

Normalize the g(eom,cache,part,...) build.

Rather then combining hardlink creation for the geom(8) binary with
shared library build, move libraries to src/lib/geom so they are
built and installed normally. Create a common Makefile.classes
which is included by both lib/geom/Makefile and sbin/geom/Makefile
so the symlink and libraries stay in sync.

The relocation of libraries allows libraries to be build for 32-bit
compat. This also reduces the number of non-standard builds in
the system.

This commit is not sufficent to run a 32-bit /sbin/geom on a 64-bit
system out of the box as it will look in the wrong place for libraries
unless GEOM_LIBRARY_PATH is set appropriatly in the environment.

Reviewed by: bdrewery
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15360

show more ...


# 22289a8c 04-Mar-2017 Enji Cooper <ngie@FreeBSD.org>

sbin: normalize paths using SRCTOP-relative paths or :H when possible

This simplifies make logic/output

MFC after: 1 month
Sponsored by: Dell EMC Isilon


# 406d87b1 09-Feb-2016 Glen Barber <gjb@FreeBSD.org>

Explicitly add more files to the 'runtime' package.

Sponsored by: The FreeBSD Foundation


# 7838c4d1 15-Dec-2010 David E. O'Brien <obrien@FreeBSD.org>

Rename the generic "CLASS" to the more specific "GEOM_CLASS".
While I'm here remove redundancy and inconsistencies.

Obtained from: Juniper Networks


# e1237b28 02-Jul-2004 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Introduce GEOM_LABEL class.
This class is used for detecting volume labels on file systems:
UFS, MSDOSFS (FAT12, FAT16, FAT32) and ISO9660.
It also provide native labelization (there is no need for f

Introduce GEOM_LABEL class.
This class is used for detecting volume labels on file systems:
UFS, MSDOSFS (FAT12, FAT16, FAT32) and ISO9660.
It also provide native labelization (there is no need for file system).

g_label_ufs.c is based on geom_vol_ffs from Gordon Tetlow.
g_label_msdos.c and g_label_iso9660.c are probably hacks, I just found
where volume labels are stored and I use those offsets here,
but with this class it should be easy to do it as it should be done by
someone who know how.
Implementing volume labels detection for other file systems also should
be trivial.

New providers are created in those directories:
/dev/ufs/ (UFS1, UFS2)
/dev/msdosfs/ (FAT12, FAT16, FAT32)
/dev/iso9660/ (ISO9660)
/dev/label/ (native labels, configured with glabel(8))

Manual page cleanups and some comments inside were submitted by
Simon L. Nielsen, who was, as always, very helpful. Thanks!

show more ...