This effectively reverts r124752.
There's no reason this should be different. It resulted in needing NO_PIE in
the original opt-out NO_PIE commit as this was not using the proper framework.
Reported by: peter
1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other
build-only utility libraries.
2. Another 40% is fixed by generating _pic.a variants of various libraries.
3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR)
where it never would work anyhow, such as csu or loader. This suggests
there may be better ways of adding support to the tree. Many of these
cases can be fixed such that -fPIE will work but there is really no
reason to have it in those cases.
4. Some of the uses are working around hacks done to some Makefiles that are
really building libraries but have been using bsd.prog.mk because the code
is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have
been needed.
We likely do want to enable PIE by default (opt-out) for non-tree consumers
(such as ports). For in-tree though we probably want to only enable PIE
(opt-in) for common attack targets such as remote service daemons and setuid
utilities. This is also a great performance compromise since ASLR is expected
to reduce performance. As such it does not make sense to enable it in all
utilities such as ls(1) that have little benefit to having it enabled.
Reported by: kib
good example is socket options that aren't necessarily generic. To
this end, OSD is added to the socket structure and hooks are defined
for key operations on sockets. These are:
o soalloc() and sodealloc()
o Get and set socket options
o Socket related kevent filters.
One aspect about hhook that appears to be not fully baked is the return
semantics (the return value from the hook is ignored in hhook_run_hooks()
at the time of commit). To support return values, the socket_hhook_data
structure contains a 'status' field to hold return values.
Submitted by: Anuranjan Shukla <anshukla@juniper.net>
Obtained from: Juniper Networks, Inc.
but shall provide an Euro sign - similar for Japanese Yen).
The Brazilian keymap "br.kbd" now has accents, by default - the no-accents
version has been renamed to "br.noacc.kbd".
MFC after: 3 days
building toolchain for the host computer. This toolchain produces
TARGET_ARCH and assumes the rest of the system contains libraries for
the target. It is intended to be used in a "qemu-user jail" where all
the binaries would otherwise be the target architecture's to build
ports. However, emulation of the compilers is too slow, so we build
native binaries for that. Rather than use the xdev produced binaries,
with all their weird links and paths, these binaries use the native
paths. They will not work unless installed into the qemu-user jail.
Differential Revision: https://phabric.freebsd.org/D518
Reviewed by: sbruno@
starting with a superpage demotion by pmap_enter() that could result in
a PV list lock being held when pmap_enter() is just about to return
KERN_RESOURCE_SHORTAGE. Consequently, the KASSERT that no PV list locks
are held needs to be replaced with a conditional unlock.
Discussed with: kib
X-MFC with: r269728
Sponsored by: EMC / Isilon Storage Division
sample size. According to the USB audio frame format specification
from USB.org, the value in the "bBitResolution" field can be less than
the actual sample size, depending on the actual hardware, and should
not be used for this computation.
PR: 192755
MFC after: 1 week
dependent encoding) to NEWCONS (Unicode).
The file "LANG.map" is used to convert INDEX.keymaps. It has 3 columns:
- the language ID as used in the source file
- the language ID to be used in the generated file (e.g. "iw" -> "he")
- the encoding of the menu texts for this language
The conversion result is written to STDOUT.
The file "KBDFILES.map" is used to batch convert keymap files. It's
columns are:
- the encoding used for the keymap sounce file
- the name of the source file
- the name of the generated file
The output files are created in the TEMP sub-directory of the vt keymap
directory, in order to preserve (possibly uncommitted) keymap files in
/usr/src/share/vt/keymaps.
The convert-keymap.pl script can be directly executed by passing the
source file name and the encoding on the command line. It writes to
STDOUT and generates hex Unicode codepoints by default. (This can be
changed to decimal in the script.)
While written for the one-time conversion of the SYSCONS keymaps into
the format required for NEWCONS, I think these tools may be useful for
easy conversion of possible further SYSCONS keymap files, that have not
been committed to the source tree.
header (Elf_Ehdr) to determine if a particular interpretor wants to
accept it or not. Use this mechanism to filter EABI arm on OABI arm
kernels, and vice versa. This method could also be used to implement
OABI on EABI arm kernels, if desired, or to allow a single mips kernel
to run o32, n32 and n64 binaries.
Differential Revision: https://reviews.freebsd.org/D609
I have spent many hours comparing source and destination formats, and hope
to have caught the most severe conversion errors.
Files were converted with a Perl script which I'll shortly commit to the
tools directory. This script is a much enhanced version of the one
provided by ray@ and is expected to support the full kbdmap(5) syntax.
The naming convention used is:
<2-letter country code>.<variant>.kbd
Only if there are multiple layouts for different languages:
<2-letter country code>-<2-letter language code>.<variant>.kbd
In nearly all cases, the keyboards are country specific, only. Currently
there is only one case where the language was added ("ch-fr.kbd" for
the Swiss-French keyboard layout).
I choose to write Unicode character codes as hex numbers. While this
increases the diff to the SYSCONS keymap files for the trivial cases
(conversion from ISO8859-1), it really helps to verify the more complex
cases against a Unicode table (which is indexed by hex numbers).
This commit does not cover all files that have been converted, since I
need to sort out which ones to use, if there were several with different
source encodings to choose from.
Review and test of the keymap files is highly desirable before 10.1 is
released. I'd also appreciate educated opinions regarding the optimum
variant (to be made available as the default for each language).
Since there are no NEWCONS keymaps in 10-STABLE, I plan to MFC after
the minimum allowed delay of 3 days, to allow at least a few weeks to
test and improve what will be in the next release.
MFC after: 3 days
