Add systrace_linux32 and systrace_freebsd32 modules which provide
support for tracing compat system calls in addition to native system
call tracing provided by systrace module.
Provided that all the systrace modules are loaded now you can select
what syscalls to trace in the following manner:
syscall::xxx:yyy - work on all system calls that match the specification
syscall:freebsd:xxx:yyy - only native system calls
syscall:linux32:xxx:yyy - linux32 compat system calls
syscall:freebsd32:xxx:yyy - freebsd32 compat system calls on amd64
PR: kern/152822
Submitted by: Artem Belevich <fbsdlist@src.cx>
Reviewed by: jhb (earlier version)
MFC after: 3 weeks
also does this for sound drivers it's probably not necessary for all
combinations of controllers and drivers. However, given that our sound
drivers completely lack bus_dmamap_sync(9) calls this at least serves
as a workaround when enabling use of the IOMMU streaming buffers on
sparc64 and generally for arm and mips.
MFC after: 2 weeks
support for it. Note that while sparc64 also supports the static TLS
model and thus tls_model("initial-exec"), using the default model
turned out to yield slightly better buildstone performance.
- Emitt an error when encountering an unsupported and in case of the
kernel also for unaligned relocations.
- Fix R_SPARC_LOX10 relocations. Apparently these are hardly ever used.
- Add the _RF_X committed in r212998 also to the tables in the sparc64
reloc.c in order reduce differences between the kernel and the userland
source. This results in no functional change though.
- Fix further inconsistencies in the abbreviations of the names of the
relocations.
- Further whitespace fixes.
Obtained from: NetBSD [1]
* elf64-sparc.c (sparc64_elf_relocate_section): Adjust addend of
dynamic relocs against section symbols for the output section vma.
However, with the addition of TLS support in the upstream rev. 1.104
this fix was essentially reverted. After factoring out the common parts
of elf32-sparc.c and elf64-sparc.c a comment was added to elfxx-sparc.c
in the upstream rev. 1.27 as part of unrelated changes, saying that the
fix from elf64-sparc.c rev. 1.61 indeed should be implemented, but given
that some unspecified OS has a broken ld.so expecting broken relocations
deliberately is omitted.
As the current behavior actually violates the SPARC ABI, FreeBSD never
had such a broken ld.so and this is actually causing problems with at
least kernel modules linked with binutils 2.17.50 committed in r218822
without the workaround committed in r219340 in place, re-implement the
above fix in a way so that is only applied if the output format is
ELFOSABI_FREEBSD. In the upstream version it probably would make sense
to invert this check and only skip adjusting the addend for the OS with
the broken ld.so, once it's determine which one that is.
Approved by: dim
This is a minor cosmetic change - the users are more likely to want to
increase (rather than decrease) default kernel stack size,
which is already 4 pages on amd64.
MFC after: 4 days
Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
The ath9k driver has a unified boundary/pdadc function, whereas
ours is split into two (one for each EEPROM type.) This is why
the AR9280 check is done here where we could safely assume it'll
always be AR9280 or later.
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.
It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
c65292b04b98d6a76d58c5a54ca8f81463bf24de to support new SIOCGIFDESCR
ioctl interface which was too late for libpcap 1.1.1.
Reported by: brucec
Noticed by: wxs
The test was support to check if SUID/SGID bits are removed on first
write, but actually we were checking if they were removed after close.
Now we can check if SUID/SGID bits are gone after first write.
While here add checks to see if when both SUID and SGID bits are set they are
both cleared on first write.
