| Commit message (Collapse) | Author | Files | Lines |
|---|
|
A speciality of the RTEMS build system was the make preinstall step. It
copied header files from arbitrary locations into the build tree. The
header files were included via the -Bsome/build/tree/path GCC command
line option.
This has at least seven problems:
* The make preinstall step itself needs time and disk space.
* Errors in header files show up in the build tree copy. This makes it
hard for editors to open the right file to fix the error.
* There is no clear relationship between source and build tree header
files. This makes an audit of the build process difficult.
* The visibility of all header files in the build tree makes it
difficult to enforce API barriers. For example it is discouraged to
use BSP-specifics in the cpukit.
* An introduction of a new build system is difficult.
* Include paths specified by the -B option are system headers. This
may suppress warnings.
* The parallel build had sporadic failures on some hosts.
This patch removes the make preinstall step. All installed header
files are moved to dedicated include directories in the source tree.
Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc,
etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g.
erc32, imx, qoriq, etc.
The new cpukit include directories are:
* cpukit/include
* cpukit/score/cpu/@RTEMS_CPU@/include
* cpukit/libnetworking
The new BSP include directories are:
* bsps/include
* bsps/@RTEMS_CPU@/include
* bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include
There are build tree include directories for generated files.
The include directory order favours the most general header file, e.g.
it is not possible to override general header files via the include path
order.
The "bootstrap -p" option was removed. The new "bootstrap -H" option
should be used to regenerate the "headers.am" files.
Update #3254.
|
|
Update #3175.
|
|
Implement userspace gettimeofday(2) with HPET timecounter.
Right now, userspace (fast) gettimeofday(2) on x86 only works for
RDTSC. For older machines, like Core2, where RDTSC is not C2/C3
invariant, and which fall to HPET hardware, this means that the call
has both the penalty of the syscall and of the uncached hw behind the
QPI or PCIe connection to the sought bridge. Nothing can me done
against the access latency, but the syscall overhead can be removed.
System already provides mappable /dev/hpetX devices, which gives
straight access to the HPET registers page.
Add yet another algorithm to the x86 'vdso' timehands. Libc is updated
to handle both RDTSC and HPET. For HPET, the index of the hpet device
to mmap is passed from kernel to userspace, index might be changed and
libc invalidates its mapping as needed.
Remove cpu_fill_vdso_timehands() KPI, instead require that
timecounters which can be used from userspace, to provide
tc_fill_vdso_timehands{,32}() methods. Merge i386 and amd64
libc/<arch>/sys/__vdso_gettc.c into one source file in the new
libc/x86/sys location. __vdso_gettc() internal interface is changed
to move timecounter algorithm detection into the MD code.
Measurements show that RDTSC even with the syscall overhead is faster
than userspace HPET access. But still, userspace HPET is three-four
times faster than syscall HPET on several Core2 and SandyBridge
machines.
Tested by: Howard Su <howard0su@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D7473
Update #3175.
|
|
sys/sys: minor spelling fixes.
While the changes are minor, these headers are very visible.
MFC after: 2 weeks
Update #3175.
|
|
Constify the pointers to eventtimer and timecounter name strings.
The need for this appears as soon as you try to set the names to something
that isn't a "quoted literal". (I'm actually confused why quoted strings
aren't a problem as well, we must have some warning disabled.)
Update #3175.
|
|
Implement a mechanism for making changes in the kernel<->driver PPS interface without breaking ABI or API compatibility with existing drivers.
The existing data structures used to communicate between the kernel and
driver portions of PPS processing contain no spare/padding fields and no
flags field or other straightforward mechanism for communicating changes
in the structures or behaviors of the code. This makes it difficult to
MFC new features added to the PPS facility. ABI compatibility is
important; out-of-tree drivers in module form are known to exist. (Note
that the existing api_version field in the pps_params structure must
contain the value mandated by RFC 2783 and any RFCs that come along after.)
These changes introduce a pair of abi-version fields which are filled in
by the driver and the kernel respectively to indicate the interface
version. The driver sets its version field before calling the new
pps_init_abi() function. That lets the kernel know how much of the
pps_state structure is understood by the driver and it can avoid using
newer fields at the end of the structure that it knows about if the driver
is a lower version. The kernel fills in its version field during the init
call, letting the driver know what features and data the kernel supports.
To implement the new version information in a way that is backwards
compatible with code from before these changes, the high bit of the
lightly-used 'kcmode' field is repurposed as a flag bit that indicates the
driver is aware of the abi versioning scheme. Basically if this bit is
clear that indicates a "version 0" driver and if it is set the driver_abi
field indicates the version.
These changes also move the recently-added 'mtx' field of pps_state from
the middle to the end of the structure, and make the kernel code that uses
this field conditional on the driver being abi version 1 or higher. It
changes the only driver currently supplying the mtx field, usb_serial, to
use pps_init_abi().
Reviewed by: hselasky@
Update #3175.
|
|
Add mutex support to the pps_ioctl() API in the kernel. Bump kernel version to reflect structure change.
PR: 196897
MFC after: 1 week
Update #3175.
|
|
New test sptests/timecounter01.
Update #2271.
|
|
FreeBSD assumes that u_int is a 32-bit integer type. This is wrong for
some 16-bit targets supported by RTEMS.
Update #2271.
|
|
Update #2271.
|
