kevans [Thu, 18 Jan 2018 21:29:46 +0000 (21:29 +0000)]
MFC r322177: Respect SIMPLE_BACKUP_SUFFIX environment variable in indent(1)
Instead of using a non-configurable ".BAK" suffix, respect the
SIMPLE_BACKUP_SUFFIX environment variable also used by patch(1). This
simplifies cleanup operations in some patch/indent workflows.
ed [Thu, 18 Jan 2018 13:43:09 +0000 (13:43 +0000)]
MFC r327560:
Allow timed waits with relative timeouts on locks and condvars.
Even though pthreads doesn't support this, there are various alternative
APIs that use this. For example, uv_cond_timedwait() accepts a relative
timeout. So does Rust's std::sync::Condvar::wait_timeout().
Though I personally think that relative timeouts are bad (due to
imprecision for repeated operations), it does seem that people want
this. Extend the existing futex functions to keep track of whether an
absolute timeout is used in a boolean flag.
Pull in r314838 from upstream clang trunk (by Richard Smith):
Suppress -Wmissing-braces warning when aggregate-initializing a
struct with a single field that is itself an aggregate.
In C++, such initialization of std::array<T, N> types is guaranteed
to work by the standard, is completely idiomatic, and the "suggested"
alternative from Clang was technically invalid.
Together, these suppress unneeded "suggest braces around initialization
of subobject" warnings for C++11 initializer lists.
kevans [Sun, 14 Jan 2018 05:10:02 +0000 (05:10 +0000)]
MFC (conceptually) r327377: Pull in strnlen for sys/boot environment
This is a direct commit to stable/11 due to restructuring of lib/libstand =>
stand/libsa in -HEAD. The diff remains the same and it is simply applied to
the previous location.
MFC r327377: Pull in strnlen from libc
strnlen is not used at the moment, but it will be when libfdt gets updated.
Prepare for the not-so-distant future by pulling in strnlen.
This is a direct commit to stable/11 due to restructuring of sys/boot =>
stand in -HEAD. The diff remains the same and it is simply applied to the
previous location.
MFC r327376: stand/fdt: Swap libfdt include order
libfdt.h should be included before fdt.h, as hinted at by all of libfdt/;
standard include order being libfdt.h, libfdt_env.h, fdt.h.
The current include order also causes problems when libfdt gets updated, as
fdt.h requires some definitions from libfdt.h.
MFC r327416: stand/fdt: Make fdt_overlay_apply signature-compatible with
libfdt
libfdt will assume a writable fdt overlay blob has been passed in, so make
ours compatible to allow easier review when we try to drop libfdt into
place. overlay from the calling context is writable, making it safe to
simply rip out everything related to copying the overlay blob in
fdt_overlay_apply.
I note here that we still have problems: fdt_overlay_apply, both our version
and libfdt's, may fail and have already clobbered the base fdt to some
extent. Future work will make sure we don't apply a potentially bogus fdt,
instead discarding the base fdt if we had an error.
This is a direct commit to stable/11 due to restructuring of sys/boot =>
stand in -HEAD. The diff remains the same and it is simply applied to the
previous location.
This is a direct commit to stable/11 due to restructuring of sys/boot =>
stand in -HEAD. The diff remains the same and it simply applied to the
previous location.
MFC r327298: stand/fdt: Fix loading of multiple fdt_overlays
fdt_load_dtb_overlays was written to unload previous overlay when a new
valid one is come across. fdt_apply_overlays further down is written to
iterate over all .dtbo's currently loaded and apply them one-by-one. Correct
fdt_load_dtb_overlays to stop dropping valid overlays that were previously
loaded and match expectations.
MFC r327299: stand/fdt: Avoid bailout when dtbo has no fixups
In the case of a simple dtbo where fragment uses target-path and the overlay
contains no references, /__fixups__ will not be included by either our dtc
or dtc from ports, but the file still has valid fragments to be applied.
Additional testing found that /__symbols__ might also be omitted if it's
empty, which is not necessarily an error.
karels [Sat, 13 Jan 2018 14:10:05 +0000 (14:10 +0000)]
MFC r327505:
make SW_WATCHDOG dynamic
Enable the hardclock-based watchdog previously conditional on the
SW_WATCHDOG option whenever hardware watchdogs are not found, and
watchdogd attempts to enable the watchdog. The SW_WATCHDOG option
still causes the sofware watchdog to be enabled even if there is a
hardware watchdog. This does not change the other software-based
watchdog enabled by the --softtimeout option to watchdogd.
Note that the code to reprime the watchdog during kernel core dumps is
no longer conditional on SW_WATCHDOG. I think this was previously a bug.
eadler [Sat, 13 Jan 2018 09:28:43 +0000 (09:28 +0000)]
MFC r324206:
bsdinstall(8) hardening menu: Utilize new kern.randompid=1 behaviour
Enabling the PID randomization option in bsdinstall(8)'s hardening menu
now randomizes the effective value of kern.randompid on each boot.
Previous behaviour:
When kern.randompid was enabled via the the bsdinstall(8) hardening menu,
a random value was generated and placed in the systems /etc/sysctl.conf as
kern.randompid=value
This makes the value of kern.randompid static across reboots.
New behaviour:
When kern.randompid is enabled via the bsdinstall(8) hardening menu, the
line kern.randompid=1 is placed in the systems /etc/sysctl.conf.
This takes advantage of a new kernel feature and makes the value of
kern.randompid be randomized by the kernel on each reboot.
pfg [Fri, 12 Jan 2018 17:36:19 +0000 (17:36 +0000)]
MFC r327697, r327699:
Use the __result_use_check attribute for reallocf(9).
MFC r327751:
Use the __result_use_check attribute also for reallocf(3).
The GCC attribute causes a warning to be emitted if a caller of the
function with this attribute does not use its return value. Unlike the
traditional realloc, with reallocf(3) we don't have to check for NULL
values but we still have to make sure the result is used.
cy [Fri, 12 Jan 2018 02:49:18 +0000 (02:49 +0000)]
MFC 327737:
USNO and possibly others have misinterpreted the maining of the
leapseconds last-update field and incorrectly increment it when changing
the file even though the leapsecond data has not changed. For instance,
if a leapsecond file is obtained from USNO, when it expires it will not
be replaced by a newer file from other sources because it has an
incorrect later last-update (version).
asomers [Fri, 12 Jan 2018 00:31:07 +0000 (00:31 +0000)]
MFC r313962, r313972-r313973, r315230
r313962 by allanjude:
improve PBKDF2 performance
The PBKDF2 in sys/geom/eli/pkcs5v2.c is around half the speed it could be
GELI's PBKDF2 uses a simple benchmark to determine a number of iterations
that will takes approximately 2 seconds. The security provided is actually
half what is expected, because an attacker could use the optimized
algorithm to brute force the key in half the expected time.
With this change, all newly generated GELI keys will be approximately 2x
as strong. Previously generated keys will talk half as long to calculate,
resulting in faster mounting of encrypted volumes. Users may choose to
rekey, to generate a new key with the larger default number of iterations
using the geli(8) setkey command.
Security of existing data is not compromised, as ~1 second per brute force
attempt is still a very high threshold.
r313973 by ngie:
A forced commit to note other portion of the Makefile change accidentally
committed in r313972
The code committed in r313962 implicitly relies on python 2.x to generate
testvect.h . There are a handful of issues with this approach:
- python is not an explicit build dependency for FreeBSD
- python 2.x is deprecated and will be removed sometime in the future
(potentially before 11.x's EOL), and the script does not function with
python 3.5 (it uses deprecated idioms and incompatible function calls).
- python(1) (by default) lives in /usr/local/bin (${LOCALBASE}/bin) and
gentestvect.py is a dependency of testvect.h (prior to r313972) which
means that if the mtime of the generator script was newer than the
mtime of the test vector, it could cause a spurious build failure in
build time or at install time.
r315230 by ngie:
Move .../sys/geom/eli/pbkdf2... to .../sys/geom/class/eli/...
This change moves the tests added in r313962 to an existing directory
structure used by the geli TAP tests. It also, renames the test from
pbkdf2 to pbkdf2_test .
The changes to ObsoleteFiles.inc are being committed separately as they
aren't needed for the MFC to ^/stable/11, etc, if the MFC for the tests
is done all in one commit.
asomers [Fri, 12 Jan 2018 00:25:56 +0000 (00:25 +0000)]
MFC r309373 (by bdrewery)
Fix setrlimit_test:setrlimit_memlock when the system has exceeded vm.max_wired.
This uses the same fix as r294894 did for the mlock test. The code from
that commit is moved into a common object file which PROGS supports
building first.
asomers [Thu, 11 Jan 2018 23:57:55 +0000 (23:57 +0000)]
MFC r326640:
Optimize telldir(3)
Currently each call to telldir() requires a malloc and adds an entry to a
linked list which must be traversed on future telldir(), seekdir(),
closedir(), and readdir() calls. Applications that call telldir() for every
directory entry incur O(n^2) behavior in readdir() and O(n) in telldir() and
closedir().
This optimization eliminates the malloc() and linked list in most cases by
packing the relevant information into a single long. On 64-bit architectures
msdosfs, NFS, tmpfs, UFS, and ZFS can all use the packed representation. On
32-bit architectures msdosfs, NFS, and UFS can use the packed
representation, but ZFS and tmpfs can only use it for about the first 128
files per directory. Memory savings is about 50 bytes per telldir(3) call.
Speedup for telldir()-heavy directory traversals is about 20-30x for one
million files per directory.
asomers [Thu, 11 Jan 2018 23:56:55 +0000 (23:56 +0000)]
MFC r326624:
cam: fix sign-extension error in adagetparams
adagetparams contains a sign-extension error that will cause the sector
count to be incorrectly calculated for ATA disks of >=1TiB that still use
CHS addressing. Disks using LBA48 addressing are unaffected.
ian [Thu, 11 Jan 2018 17:51:22 +0000 (17:51 +0000)]
Do not build lint(1) by default on stable-11, add WITH_LINT to enable
building it.
lint(1) is required on the host build system to build lint(1) libraries, and
it is no longer available on FreeBSD 12. This prevents using a 12 or later
host to build an 11 or earlier system, which causes problems for building
jails and using poudriere. The problem could be fixed by treating lint as a
bootstrap tool when building on 12+, but that just adds complexity and build
time to build a broken tool that virtually nobody uses anymore.
This is a direct commit to 11-stable because lint no longer exists in later
branches.
pfg [Wed, 10 Jan 2018 21:17:33 +0000 (21:17 +0000)]
MFC r327289:
rpc.sprayd: Bring some changes from NetBSD.
Most notable, other than some style issues:
CVS 1.11:
do not use LOG_CONS.
CVS 1.13:
consistently use exit instead of return in main().
use LOG_WARNING instead of LOG_ERR for non critical errors.
emaste [Tue, 9 Jan 2018 00:27:02 +0000 (00:27 +0000)]
MFC r327489: elfcopy: copy raw (untranslated) contents to binary output
Previously elfcopy used elf_getdata to obtain data from ELF sections
being copied to binary output, but elf_getdata returns data that has
been translated - that is, data is in host byte order. When the host and
target differ in endianness (e.g., converting a big-endian MIPS ELF
object to binary on an x86 host) this resulted in byte-swapped data in
certain sections such as .dynamic.
Instead use elf_rawdata to keep data in the original, target endianness.
Reported by: Hiroki Mori <yamori83@yahoo.co.jp>, Bill Yuan
Sponsored by: The FreeBSD Foundation
bapt [Sun, 7 Jan 2018 10:29:15 +0000 (10:29 +0000)]
MFC r326769:
Remove hard coded number of lun definition
The number of lun exposed is now exposed via sysctl by the kernel.
Use that number in ctlstat instead of the hardcoded version
Add a backward compatibility in case the sysctl(2) request fails.
This also allows ctlstat -l 1118 to actually work when having more than
1024 luns.
Reviewed by: avg, manu (both before the backward compatibility addition)
Approved by: avg, manu (both before the backward compatibility addition)
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D13446
ian [Sun, 7 Jan 2018 02:59:27 +0000 (02:59 +0000)]
MFC r327220-r327221
r327220:
Update the FDT example for the lm75 sensor to match current devicetree
standards and what the existing driver expects.
Also change 'like' to 'such as' where the text is providing an example
rather than a simile.
r327221:
Complete the changing of the old "i2c-address" property to the modern "reg"
property by updating the description text to match the updated example.
ian [Sun, 7 Jan 2018 02:57:35 +0000 (02:57 +0000)]
MFC r327222:
Add a new ARM kernel option, LOCORE_MAP_MB, to control the size of the
kernel VA mapping in the temporary page tables set up by locore-v6.S.
The number used to be hard-coded to 64MB, which is still the default if
the kernel option is not specified. However, 64MB is insufficient for
using a large mdroot filesystem. The hard-coded number can't be safely
increased because too large a number may run into memory-mapped IO space
on some SoCs that must not be mapped as ordinary memory.
ian [Sun, 7 Jan 2018 01:08:10 +0000 (01:08 +0000)]
MFC r327226, r327356
r327226:
Add a section describing how to tune ARM kernel options to use an MD_ROOT
filesystem larger than about 50-55 MiB.
The description of VM_KMEM_SIZE_SCALE is roughly as hand-wavy as my
understanding of the option, but at least mentioning that it's a factor
and giving an empirical datapoint that works will give folks some idea
of what to tweak if they have problems.
r327356:
Correct a mistake and reword a couple sentences to clarify that "the value"
refers to the scale value, not the kmem_arena size that results from scaling.
ian [Sun, 7 Jan 2018 01:06:04 +0000 (01:06 +0000)]
MFC r327439:
Allow use of .WAIT in the LOCAL_DIRS and LOCAL_LIB_DIRS lists.
A comment in Makefile.inc1 has long stated that LOCAL_DIRS are built last,
after the base system. Incremental improvements in parallel building over
the years have led to LOCAL_DIRS being built in parallel with base system
directories. This change allows the .WAIT directive to appear in LOCAL_DIRS
and LOCAL_LIB_DIRS lists to give the user some control over parallel
building of local additions.
ian [Sun, 7 Jan 2018 00:04:13 +0000 (00:04 +0000)]
MFC r327367:
Make kernel option KERNVIRTADDR optional, remove it from std.<platform>
files that can use the default value.
It used to be required that the low-order bits of KERNVIRTADDR matched
the low-order bits of the physical load address for all arm platforms.
That hasn't been a requirement for armv6 platforms since FreeBSD 10.
There is no longer any relationship between load addr and KERNVIRTADDR
except that both must be aligned to a 2 MiB boundary.
This change makes the default KERNVIRTADDR value 0xc0000000, and removes the
options from all the platforms that can use the default value. The default
is now defined in vmparam.h, and that file is now included in a few new
places that reference KERNVIRTADDR, since it may not come in via the
forced-include of opt_global.h on the compile command line.
ian [Sat, 6 Jan 2018 23:24:52 +0000 (23:24 +0000)]
MFC r327048-r327050
r327048:
Restore the ability to use EARLY_PRINTF support during most of initarm().
The real kernel page tables are set up much earlier in initarm() now than
they were when early printf support was first added, and they end up undoing
the mapping made in locore.S for early printf support. This re-adds the
mapping after switching to the new/real kernel page tables, making early
printf work again right after switching to them.
r327049:
Allow pmap_kremove() to remove 1MB section mappings as well as 4K pages.
This will allow it to undo temporary device mappings such as those made
with pmap_preboot_map_attr().
Reviewed by: cognet
r327050:
If a temporary mapping is made to support EARLY_PRINTF, undo that mapping
after cninit() runs, otherwise we leave a bogus device-memory mapping in
userspace VA in the kernel pmap forever.
ian [Sat, 6 Jan 2018 23:20:35 +0000 (23:20 +0000)]
MFC r327032:
Add a new kernel config option, MD_ROOT_READONLY, which forces on the
MD_READONLY flag for the md device automatically instantiated during
kernel init for an mdroot filesystem.
Note that there is specifically and by design no tunable or sysctl
control over this feature. Without this option, you already have control
over whether the mdroot fs is writeable using vfs.root.mountfrom.options
from loader(8), the root_rw_mount rcvar, and by using "mount -u[rw] /"
or equivelent on the fly. This option is being added to provide a way
to make the mdroot fs truly immutable before userland code begins running.
ian [Sat, 6 Jan 2018 23:12:32 +0000 (23:12 +0000)]
MFC r326924-r326925
r326924:
Fix debugging output, fallout from something like s/read/readctl/g
while renaming variables in a previous change.
r326925:
Do not attempt to refill the TX fifo if there is no data left to transfer.
A comment in bcm_bsc_fill_tx_fifo() even lists sc_totlen > 0 as a
precondition for calling the routine. I apparently forgot to make the
code do what my comment said.
ian [Sat, 6 Jan 2018 23:04:14 +0000 (23:04 +0000)]
MFC r326750:
Do not give up if writing to the chip's control and status registers fails
during startup. When a brand new chip leaves the factory, it is in a
special power-saving mode that disables most functions on the chip to
save battery power. The chip is stuck in this mode until the first write
to the time registers, which automatically clears the special power-saving
mode and starts the oscillator.
Also, the day-of-week register in this chip counts 1-7, not 0-6, so write
the values accordingly.
These changes are based on the patch submitted by Brian Scott, but I
elimated warnings since this condition is expected, and added some comments,
and so in general blame me for any mistakes.
ian [Sat, 6 Jan 2018 22:56:48 +0000 (22:56 +0000)]
MFC r325108:
Improve the performance of the hpet timer in bhyve guests by making the
timer frequency a power of two. This changes the frequency from 10 to
16.7 MHz (2 ^ 24 HZ). Using a power of two avoids roundoff errors when
doing arithmetic in sbintime_t units.
Testing shows this can fix erratic ntpd behavior in guests using the
hpet timer (which is the default for multicore guests).
r325045:
Actually release resources in detach() rather than just returning EBUSY.
This will enable use of 'devctl disable', allow creation of a module, etc.
r325054:
Increase the alignment of the rx/tx descriptor ring buffers to 64 bytes.
16 was the correct alignment for older hardware, but the imx7 requires
64-byte alignment, which is a fine value to use on all systems.
r325055:
Add FECFLAG_AVB variant flag to support new features on imx7.
This flag is analogous to the Linux driver FEC_QUIRK_HAS_AVB. It
indicates an FEC with support for Audio Video Bridging (AVB). This
indicator is used for various other parts in the Linux driver
(drivers/net/ethernet/freescale/fec_main.c).
Use it to customize the receive/transmit buffer alignment. The receive
buffer alignment increased to 64-bytes on the i.MX 6SoloX and i.MX
7Dual. There are no hard alignment restrictions for transmit buffers on
these chips.
Fix the ffec_softc::fectype type to provide enough storage for the
feature flags.
r325056:
Avoid AXI bus issues due to a MAC reset on imx6sx and imx7.
When the FEC is connected to the AXI bus (indicated by AVB flag), a
MAC reset while a bus transaction is pending can hang the bus.
Instead of resetting, turn off the ENABLE bit, which allows the
hardware to complete any in-progress transfers (appending a bad CRC
to any partial packet) and release the AXI bus. This could probably
be done unconditionally for all hardware variants, but that hasn't
been tested.
Newer hardware splits the interrupts onto 3 different irq lines, but the
docs barely mention that there are multiple interrupts, and do not detail
how they're split up. The code now supports 1-3 irqs, and uses the same
interrupt service routine to handle all of them.
I modified the submitted changes to use bus_alloc_resources() instead of
using loops to allocate each irq separately. Thus, blame any bugs on me (I
can't actually test on imx7 hardware).
r325063:
Use the 16-bit receive shift feature in ffec hardware that supports it.
When available, enabling this feature causes the hardware to write data
to the receive buffer starting at a 16-bit offset from the start address.
This eliminates the need to copy the data after receiving to re-align
the protocol headers to a 32-bit boundary.
r325065:
Split the hardware type enum and the hw feature flags bits into separate
fields in the softc; they're ORed together in the ofw_compat_data.
I already caught myself doing 'sc->fectype == <enum val>' without masking
out the feature bits in one place, and that's sure to happen again.
Glomming them together is convenient for storing them in the ofw_compat_data
array, but there's no reason to keep them together in the softc.
ian [Sat, 6 Jan 2018 20:52:30 +0000 (20:52 +0000)]
MFC r325060:
Add a #define RESOURCE_SPEC_END. Similar to DEVMETHOD_END and
KOBJMETHOD_END, this is to serve as the end marker in an array of
resource_spec structures.
ian [Sat, 6 Jan 2018 19:24:49 +0000 (19:24 +0000)]
Fix imx6 hdmi init after r323553.
This is a direct commit to 11-stable because major architectural changes in
12 prevent a direct MFC of the affected code. Conceptually, this is...
MFC r324416:
Fix imx6 hdmi init after r323553, which used a config_intrhook to defer the
attachment of i2c devices needed by hdmi.
The hdmi init also uses an intrhook callback to defer initialization, and if
the hdmi callback runs first, the i2c devices will not yet have registered
their device_t in association with their FDT phandle, which allows cross-
device references on FDT systems.
Now the hdmi deferred init checks for the i2c device registration, and if
it's not complete yet, it registers as an eventhandler watching for newbus
attach events. When the i2c device eventually attaches, the hdmi driver
unregisters from watching further events, and continues with the hdmi init.
Because the function signatures for an intrhook callback and an event
handler callback are the same, a single function is used for both callbacks.
ian [Sat, 6 Jan 2018 17:20:58 +0000 (17:20 +0000)]
MFC r324413, r324415
r324413:
Restore the ability to deregister an eventhandler from within the callback.
When the EVENTHANDLER(9) subsystem was created, it was a documented feature
that an eventhandler callback function could safely deregister itself. In
r200652 that feature was inadvertantly broken by adding drain-wait logic to
eventhandler_deregister(), so that it would be safe to unload a module upon
return from deregistering its event handlers.
There are now 145 callers of EVENTHANDLER_DEREGISTER(), and it's likely many
of them are depending on the drain-wait logic that has been in place for 8
years. So instead of creating a separate eventhandler_drain() and adding it
to some or all of those 145 call sites, this creates a separate
eventhandler_drain_nowait() function for the specific purpose of
deregistering a callback from within the running callback.
r324415:
Add eventhandler notifications for newbus device attach/detach.
The detach case is slightly complicated by the fact that some in-kernel
consumers may want to know before a device detaches (so they can release
related resources, stop using the device, etc), but the detach can fail. So
there are pre- and post-detach notifications for those consumers who need to
handle all cases.
A couple salient comments from the review, they amount to some helpful
documentation about these events, but there's currently no good place for
such documentation...
Note that in the current newbus locking model, DETACH_BEGIN and
DETACH_COMPLETE/FAILED sequence of event handler invocation might interweave
with other attach/detach events arbitrarily. The handlers should be prepared
for such situations.
Also should note that detach may be called after the parent bus knows the
hardware has left the building. In-kernel consumers have to be prepared to
cope with this race.
ian [Fri, 5 Jan 2018 19:28:13 +0000 (19:28 +0000)]
MFC r324185:
Enhance the interrupt capabilities of ti_pruss driver.
The existing ti_pruss driver for the PRUSS Hardware provided by the AM335x
ARM CPU has basic interrupt capabilities. This updated driver provides some
more options:
- Sysctl based configuration for the interrupts (for some examples, see the
test plan in the phabricator review cited below).
- A device file (/dev/pruss0.irqN) for each enabled interrupt. This file
can be read and the device blocks if no irq has happened or returns an
uint64_t timestamp based on nanouptime().
- Each interrupt device file provides kqueue-based event notification,
blocking read(), or select().
Submitted by: Manuel Stuhn <freebsdnewbie@freenet.de>
Differential Revision: https://reviews.freebsd.org/D11959
ian [Fri, 5 Jan 2018 19:21:45 +0000 (19:21 +0000)]
MFC r324169:
Work around bcm283x silicon bugs to make i2c repeat-start work for the most
common case where it's needed -- a write followed by a read to the same slave.
The i2c controller in this chip only performs complete transfers, it does
not provide control over start/repeat-start/stop operations on the bus.
Thus, we have gotten a full stop/start sequence rather than a repeat-start
when doing a typical i2c slave access of "write address, read data". Some
i2c slave devices require a repeat-start to work correctly.
These changes cause the controller to do a repeat-start by pre-staging the
read parameters in the controller registers immediate after the controller
has latched the values for the initial write operation, but before any
bytes are actually written. With the values pre-staged, when the write
portion of the transfer completes, the state machine in the silicon sees
a new start operation already staged and that causes it to perform a
repeat-start. The key to tricking the buggy hardware into doing this is
to avoid prefilling any output data in the transmit FIFO so that it is
possible to catch the silicon in the state where transmit values are
latched but the transmit isn't completed yet.
ian [Fri, 5 Jan 2018 19:12:36 +0000 (19:12 +0000)]
MFC r319987, r324107-r324108
r319987 (MFC'd just to make following changes apply cleanly):
Replace md(4) usage in diskless(8) script rc.initdiskless with tmpfs(5).
Need to multiply the size of the disk passed to mount_md by 512 as mdmfs
expects number of 512-byte blocks while tmpfs size option wants number of
bytes.
r324107:
Enhance mdmfs(8) to work with tmpfs(5).
Existing scripts and associated config such as rc.initdiskless, rc.d/var,
and others, use mdmfs to create memory filesystems. That program accepts a
size argument which allows SI suffixes and treats an unsuffixed number as a
count of 512 byte sectors. That makes it difficult to convert existing
scripts to use tmpfs instead of mdmfs, because tmpfs treats unsuffixed
numbers as a count of bytes. The script logic to deal with existing user
config that might include suffixed and unsuffixed numbers is... unpleasant.
Also, there is no g'tee that tmpfs will be available. It is sometimes
configured out of small-resource embedded systems to save memory and flash
storage space.
These changes enhance mdmfs(8) so that it accepts two new values for the
'md-device' arg: 'tmpfs' and 'auto'. With tmpfs, the program always uses
tmpfs(5) (and fails if it's not available). With 'auto' the program prefers
tmpfs, but falls back to using md(4) if tmpfs isn't available. It also
handles the -s <size> argument so that the mdconfig interpetation of
unsuffixed numbers applies when tmpfs is used as well, so that existing user
config keeps working after a switch to tmpfs.
A new rc setting, mfs_type, is added to etc/defaults/rc.conf to let users
force the use of tmpfs or md; the default value is "auto".