One of the major pain points with how this was implemented
is the requirement of in-tree, hard-coded <name>.ucl, as
well as <name>-<suffix>.ucl where <suffix> can be lib32,
profile, development, debug, or any combination of the four.
This created significant overhead when adding new packages
and any of the files in any of the combinations were missing.
Instead of test(1)-ing if the <packagename>.ucl file exists,
hand off to a script to figure out what the final ucl file
name should be before invoking pkg(8).
The default behavior is 'template.ucl' is used as a fallback.
This affects only the userland packages, as the kernel code
is already smart enough to handle these variations.
Sponsored by: The FreeBSD Foundation
sysrc(8) supports key+=value and key-=value, but can be told what the
delimiter is by being passed as char1 (e.g., "sysrc key+=",value" to use a
comma as the delimiter instead of space). For convenience, if the first char
is alpha-numeric, it is assumed you wanted whitespace as the delimiter.
However, if you naively (as I just did) execute:
sysrc rc_conf_files+=/etc/rc.conf.other
the result is unexpected.
This commit makes `.' and `/' in-addition to alpha-numeric first-characters
to cause the default of whitespace to be used as the delimiter. This also
means that you can no longer use these as a delimiter.
When using col(1) piped to vim(1) as pager for man(1), the former sequence
of (Qo \ Qc) renders as "" without the space. Replace with (Qo (space) Qc)
which renders properly in more (all?) pagers.
instead of hiding behind pmap_map_chunk(). It's not longer needed
after old pmap-v6 code was removed.
For compatibility with __ARM_ARCH < 6, define PTE_DEVICE in devmap.c
file. Certainly, it would be nice if VM_MEMATTR_DEVICE could be used
even for __ARM_ARCH < 6.
do not depend on pmap internals. This is a preparation for hiding
internal pmap definitions as much as possible from the rest of system.
Simultaneously, the protection argument evaluation is fixed. Happily,
it did not effect the mappings. And it's the reason why it was not fixed
earlier.
Only 'installworld' needs to be protected and only when not using
-DNO_ROOT, which implies not installing to / and not needing the
lib dependency protections.
Sponsored by: EMC / Isilon Storage Division
you over if you happen to use git for FreeBSD development, as it is
the case with the unbound/.gitignore, which lits files that are
actually required for the buildworld.
MFC after: 1 day
number of physical memory locations we can access. This is the case on
some HiKey boards that may have UEFI reserved memory dispersed through the
physical space.
Sponsored by: ABT Systems Ltd
clearing hazards.
This revision makes currently known MIPS32 Release 2 and Release 3 CPUs use
the EHB instruction when clearing hazards. So far the MIPS 74K and MIPS1004K
(somewhat) were already using the EHB. Now we add more r2 and r3 CPUs to
this list.
Also, for the cases of MIPS coherent processing systems (currently 1004K,
1074K, interAptiv and proAptiv) - define proper CCA attributes.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D5078
The symbols of libiconv from ports were changed to
have prefixed.
Since we have iconv in our libc these days, we don't
need it on 10.X and later. However, 9.X still need
this.
Spotted by: Yoshihiko Sarumaru
MFC after: 1 days
to open the device in exclusive mode as, without this, the firmware may
also be reading packets off the interface leading to a race.
Reviewed by: emaste
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D4132
the processor and debug state registers. A flag has been added to the pcb
to tell us when to enable single stepping for a given thread.
Reviewed by: kib
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D4730
function is only called from vm_page_startup() and vm_reserv_startup().
I.e. during vm subsystem initialization. As VM_PROT_WRITE is always
used in these calls, the typo did not have any effect. Likely, it's
the reason why it wasn't discovered so long.
This revision does the following renames:
CPU_MIPS24KC -> CPU_MIPS24K
CPU_MIPS74KC -> CPU_MIPS74K
CPU_MIPS1004KC -> CPU_MIPS1004K
It also adds the following new CPU_MIPSxxx options:
CPU_MIPS24KE, CPU_MIPS34K, CPU_MIPS1074K, CPU_INTERAPTIV, CPU_PROAPTIV
CPU_MIPSxxxxKC is limiting and possibly misleading as it implies the
MIPSxxxxK CPU has no FPU.
It would be better if the CPUs are named after their standard functionalities
only and the presence or absence of FPU can then be controlled via the
CPU_HAVEFPU option.
I will send out another dependent revision that moves MIPS 32 r2 and r3
CPUs to use the EHB instruction for clearing hazards instead of NOP/SSNOP.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D5077
MD_ROOT_SIZE and embed_mfs.sh were basically retired as part of
https://reviews.freebsd.org/D2903 .
However, when building a kernel with 'options MD_ROOT_SIZE' specified, this
results in a non-working MFS, as within sys/dev/md/md.c we fall within the
wrong # ifdef.
This patch implements the following:
* Allow kernels to be built without the MD_ROOT_SIZE option, which results
in a kernel built as per D2903.
* Allow kernels to be built with the MD_ROOT_SIZE option, which results
in a kernel built similarly to the pre-D2903 way, with the following
differences:
* The MFS is now put in a separate section within the kernel (oldmfs,
so it differs from the mfs section introduced by D2903).
* embed_mfs.sh is changed, so it looks up the oldmfs section within the
kernel, gets its size and offset, sees if the MFS will fit within the
allocated oldmfs section and only if all is well does a dd of the MFS
image into the kernel.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D5093
Some hardware supports AES acceleration but not SHA1, e.g., AES-NI
extensions. It is useful to have accelerated AES even if SHA1 must be
software.
Suggested by: asomers
Reviewed by: asomers, dfr
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D5146
