MFC r345480, r346013r345480:Support device-independent labels for geom_flashmap slices.While geom_flashmap has always supported label names for its slices, it doesso by appending "s.labelname"
MFC r345480, r346013r345480:Support device-independent labels for geom_flashmap slices.While geom_flashmap has always supported label names for its slices, it doesso by appending "s.labelname" to the provider device name, meaning you stillhave to know the name and unit of the hardware device to use the labels.These changes add support for device-independent geom_flashmap labels, usingthe standard geom_label infrastructure. geom_flashmap now creates a softcstruct attached to its geom, and as it creates slices it stores the labelinto an array in the softc. The new geom_label_flashmap uses those labelswhen tasting a geom_flashmap provider.Differential Revision: https://reviews.freebsd.org/D19535r346013:Add g_label_flashmap.c to the module, should have been part of r345480.
show more ...
MFC r344479 (by sobomax), r344605:Modularize xz.
Fix LINT build.Approved by: delphij
sys/modules: normalize .CURDIR-relative paths to SRCTOPThis simplifies make output/logicTested with: `cd sys/modules; make ALL_MODULES=` on amd64MFC after: 1 monthSponsored by: Dell EMC Isilon
Fix "make depend" with geom_uzip.ko: add opt_geom.h to SRCSMFC after: 1 weekSponsored by: Dell EMC Isilon
- Allow different slicers for different flash types to be registered with geom_flashmap(4) and teach it about MMC for slicing enhanced user data area partitions. The FDT slicer still is the defau
- Allow different slicers for different flash types to be registered with geom_flashmap(4) and teach it about MMC for slicing enhanced user data area partitions. The FDT slicer still is the default for CFI, NAND and SPI flash on FDT-enabled platforms.- In addition to a device_t, also pass the name of the GEOM provider in question to the slicers as a single device may provide more than provider.- Build a geom_flashmap.ko.- Use MODULE_VERSION() so other modules can depend on geom_flashmap(4).- Remove redundant/superfluous GEOM routines that either do nothing or provide/just call default GEOM (slice) functionality.- Trim/adjust includesSubmitted by: jhibbits (RouterBoard bits)Reviewed by: jhibbits
Remove pc98 support completely.I thank all developers and contributors for pc98.Relnotes: yes
Fix alignment issues on MIPS: align the pointers properly.All the 5520 GEOM_ELI tests passed successfully on MIPS64EB.Sponsored by: DARPA, AFRLSponsored by: HEIF5Differential Revision: https://
Fix alignment issues on MIPS: align the pointers properly.All the 5520 GEOM_ELI tests passed successfully on MIPS64EB.Sponsored by: DARPA, AFRLSponsored by: HEIF5Differential Revision: https://reviews.freebsd.org/D7905
Disable geom_eli module build on MIPS64 as it has alignmentissues and causes kernel panic.ELI metadata is also not aligned properly for MIPS64 case.Sponsored by: DARPA, AFRLSponsored by: HEIF5
Obsolete mkulzma(8) and geom_uncompress(4), their functionalityis now provided by mkuzip(8) and geom_uzip(4) respectively.MFC after: 1 month
Improve mkuzip(8) and geom_uzip(4), merge in LZMA support from mkulzma(8)and geom_uncompress(4):1. mkuzip(8): - Proper support for eliminating all-zero blocks when compressing an image. This
Improve mkuzip(8) and geom_uzip(4), merge in LZMA support from mkulzma(8)and geom_uncompress(4):1. mkuzip(8): - Proper support for eliminating all-zero blocks when compressing an image. This feature is already supported by the geom_uzip(4) module and CLOOP format in general, so it's just a matter of making mkuzip(8) match. It should be noted, however that this feature while it sounds great, results in very slight improvement in the overall compression ratio, since compressing default 16k all-zero block produces only 39 bytes compressed output block, which is 99.8% compression ratio. With typical average compression ratio of amd64 binaries and data being around 60-70% the difference between 99.8% and 100.0% is not that great further diluted by the ratio of number of zero blocks in the uncompressed image to the overall number of blocks being less than 0.5 (typically). However, this may be important from performance standpoint, so that kernel are not spinning its wheels decompressing those empty blocks every time this zero region is read. It could also be important when you create huge image mostly filled with zero blocks for testing purposes. - New feature allowing to de-duplicate output image. It turns out that if you twist CLOOP format a bit you can do that as well. And unlike zero-blocks elimination, this gives a noticeable improvement in the overall compression ratio, reducing output image by something like 3-4% on my test UFS2 3GB image consisting of full FreeBSD base system plus some of the packages (openjdk, apache etc), about 2.3GB worth of file data (800+MB compressed). The only caveat is that images created with this feature "on" would not work on older versions of FeeBSDxi kernel, hence it's turned off by default. - provide options to control both features and document them in manual page. - merge in all relevant LZMA compression support from the mkulzma(8), add new option to select between both. - switch license from ad-hoc beerware into standard 2-clause BSD.2. geom_uzip(4): - implement support for de-duplicated images; - optimize some code paths to handle "all-zero" blocks without reading any compressed data; - beef up manual page to explain that geom_uzip(4) is not limited only to md(4) images. The compressed data can be written to the block device and accessed directly via magic of GEOM(4) and devfs(4), including to mount root fs from a compressed drive. - convert debug log code from being compiled in conditionally into being present all the time and provide two sysctls to turn it on or off. Due to intended use of the module, it can be used in environments where there may not be a luxury to put new kernel with debug code enabled. Having those options handy allows debug issues without as much problem by just having access to serial console or network shell access to a box/appliance. The resulting additional CPU cycles are just few int comparisons and branches, and those are minuscule when compared to data decompression which is the main feature of the module. - hopefully improve robustness and resiliency of the geom_uzip(4) by performing some of the data validation / range checking on the TOC entries and rejecting to attach to an image if those checks fail. - merge in all relevant LZMA decompression support from the geom_uncompress(4), enable automatically when appropriate format is indicated in the header. - move compilation work into its own worker thread so that it does not clog g_up. This allows multiple instances work in parallel utilizing smp cores. - document new knobs in the manual page.Reviewed by: adrianMFC after: 1 monthDifferential Revision: https://reviews.freebsd.org/D5333
Make additional parts of sys/geom/eli more usable in userspaceThe upcoming GELI support in the loader reuses parts of this codeSome ifdefs are added, and some code is moved outside of existing ifd
Make additional parts of sys/geom/eli more usable in userspaceThe upcoming GELI support in the loader reuses parts of this codeSome ifdefs are added, and some code is moved outside of existing ifdefsThe HMAC parts of GELI are broken out into their own file, to separatethem from the kernel crypto/openssl dependant parts that are replacedin the boot code.Passed the GELI regression suite (tools/regression/geom/eli) Files=20 Tests=14996 Result: PASSReviewed by: pjd, delphijMFC after: 1 weekSponsored by: ScaleEngine Inc.Differential Revision: https://reviews.freebsd.org/D4699
Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.ccperciva's libmd implementation is 5-30% fasterThe same was done for SHA256 previously in r263218cperciva's implementation was lacking SHA
Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.ccperciva's libmd implementation is 5-30% fasterThe same was done for SHA256 previously in r263218cperciva's implementation was lacking SHA-384 which I implemented, validated against OpenSSL and the NIST documentationExtend sbin/md5 to create sha384(1)Chase dependancies on sys/crypto/sha2/sha2.{c,h} and replace them with sha512{c.c,.h}Reviewed by: cperciva, des, delphijApproved by: secteam, bapt (mentor)MFC after: 2 weeksSponsored by: ScaleEngine Inc.Differential Revision: https://reviews.freebsd.org/D3929
Scheduling module to introduce a fixed delay into the I/O path.
Kill MFILES and find things automatically. It turned out to be onlylightly used. Find the proper .m file when we depend on *_if.[ch] inthe srcs line, with seat-belts for false positive matches. Th
Kill MFILES and find things automatically. It turned out to be onlylightly used. Find the proper .m file when we depend on *_if.[ch] inthe srcs line, with seat-belts for false positive matches. This usesmake's path mechanism. A further refinement would be to calculate thisonce, and then pass the resulting _MPATH to modules submakes.Differential Revision: https://reviews.freebsd.org/D2327
Add makefile to build geom_map kld. Document some GEOM_* optionsin NOTES and geom(4).
Add MK_CCD knob for building and installing ccd(4), ccdconfig, etcMFC after: 2 weeksSponsored by: EMC / Isilon Storage Division
Remove comments relevant to 6.x only.
Remove support for FreeBSD 7 and really old FreeBSD 8. The classifiershave been in the base for a while, so the gymnastics here aren'tneeded. In addition, the bugs in subr_disk.c have been fixed si
Remove support for FreeBSD 7 and really old FreeBSD 8. The classifiershave been in the base for a while, so the gymnastics here aren'tneeded. In addition, the bugs in subr_disk.c have been fixed since2009, so there's no need for an identical copy of it in the treeanymore. There's really no need to binary patch g_io_request, so let'sget rid of the code (not compiled in anymore) lest others think it isa good idea.
Implement the historic DIOCGDINFO ioctl for gpart on BSDpartitions. Several utilities still use this interface and requireadditional information since gpart was activated than before. Thisallows f
Implement the historic DIOCGDINFO ioctl for gpart on BSDpartitions. Several utilities still use this interface and requireadditional information since gpart was activated than before. Thisallows fsck of a UFS partition without having to specify it is UFS,per historic behavior.
Add disklabel64 support to GEOM_PART class.This partitioning scheme is used in DragonFlyBSD. It is similar toBSD disklabel, but has the following improvements:* metadata has own dedicated place a
Add disklabel64 support to GEOM_PART class.This partitioning scheme is used in DragonFlyBSD. It is similar toBSD disklabel, but has the following improvements:* metadata has own dedicated place and isn't accessible through partitions;* all offsets are 64-bit;* supports 16 partitions by default (has reserved place for more);* has reserved place for backup label (but not yet implemented);* has UUIDs for partitions and partition types;No objections from: geomMFC after: 2 weeksRelnotes: yes
Disconnect the following geom classes from the kernel modules build:BSD, FOX, MBR, PC98, SUNLABEL and VOL_FFS. They all have a modernreplacement. Also it is still possible build them manually.Dis
Disconnect the following geom classes from the kernel modules build:BSD, FOX, MBR, PC98, SUNLABEL and VOL_FFS. They all have a modernreplacement. Also it is still possible build them manually.Discussed with: geom
An all-or-nothing approach to labels isn't flexible enough. Embeddedsystems need fine-grained control over what's in and what's out.That's ideal. For now, separate GPT labels from the rest and allo
An all-or-nothing approach to labels isn't flexible enough. Embeddedsystems need fine-grained control over what's in and what's out.That's ideal. For now, separate GPT labels from the rest and allowg_label to be built with just GPT labels.Obtained from: Juniper Networks, Inc.
I clearly didn't test the modules... add sha256c.c to the variousmodules that included sha2.c...
Fix a leftover of r260523. Remove the unnecessary dependency to zlib.h.Approved by: adrian (mentor)
1234