Mostly just additions of new primitives and hook functions that are
relatively straightforward and mostly copied from FreeBSD. The one
notable set of changes is the ones relating to gDevices, as the hacks
we used previously to hide the base device are now no longer needed
(as the previous commit noted.)
Previous versions of FreeBSD created a base ifp of type IFT_IEEE80211
in addition to the ifp created for each VAP. We ignored these, so that
the devices we displayed (/dev/.../0, etc.) were numbered properly.
FreeBSD 11 no longer does this and instead uses an ieee80211com as its base
type, so this logic is not needed.
* Don't translate internally used names in BMenuBars.
* Use presentable strings for the title of BAlerts.
* Make the wording a bit less technical.
Should the HaikuServer URL be part of the update/remove rating alert?
Change-Id: I0a984082eadbc5834ac6b8b2b1955e66098d1c8a
* netcat is now provided via a package and is not required by the
'haiku' package
* Display the full name of ACPICA and update copyright year
* Update copyrights for libpng.
The first two have the same license and are also now covered by
intellinuxwireless.org. The second two also share a license among
themselves, and also with following (not-yet-imported) firmware,
e.g. from idualwifi3160.
Added recent folder limit as class member but
defaulted the value to 10.
Stopped using index to keep track of selected
path and folder menu item. Instead use BMessage to send
clicked folder path to the folder bg image loader.
Change-Id: I6b1809ff782db839ef43eb7169a7f6e77fb4ec70
Fixes#5026
You still cannot boot to desktop under SMAP on intel_extreme, however,
as the agp_gart bus has not been patched properly. Doing so breaks the
intel_extreme accelerant, so more investigation is needed.
+ has greater operator precendence than ?, so we need parentheses when
using both in expressions. Both of these look like actual bugs.
Spotted by Clang.
joystick_info contains BLists which initialize themselves upon new(),
and Clang warned (correctly) that using memset() overwites that, as well as
RTTI and other data that they contain. So instead, only memset the first
part of the struct, and then manually initialize the other members.
Fixes#14217.
In 02cb8503d2, I added the m_next and
m_nextpkt structures to mbuf, as per FreeBSD's mbufq system that
FreeBSD 11.1's net80211 code uses. What I didn't realize (and
korli and PulkoMandy who reviewed my code didn't notice either)
is that the data fields in mbuf are sometimes dealt with through
these LEN macros, which were now incorrect after such changes.
This caused an out-of-bounds memory write for data above a certain
size that was attempting to be written into an mbuf that under the
old sizing would have been fine, but under this new sizing was invalid,
and this manifested itself as a KDL under the guarded_heap (#14207).
It possibly also manifested itself as a stack-smash with the new net80211
code (uncommitted on a local machine, and the reason I tried using
the guarded heap in the first place.)
Now we use FreeBSD 11's macros, which use offsetof instead of raw
integer math. This means that we can't specify the struct size in mbuf
as these structs are computed from mbuf's definition, and thus have
to rely on the allocator giving mbuf the correct size (as FreeBSD
does also.)
FreeBSD's is presently 46 bytes. CID 1422869 warns that it can get overrun
in if_attach() in copying if_xname which is IF_NAMESIZE bytes (32).
This breaks ABI, but BeOS did not have sockaddr_dl, it is only a modern-GCC
ABI break. Since most applications assume that sockaddr_dl is variable-length
and is null-terminated, as well as not used very often, hopefully this will
require relatively few rebuilds.
No functional change. Ideally we would create these via ResAttr like we do
the mail-providers, but these have attributes on their directories and not
just the files, so that will be slightly trickier, so for now just keep them
in their zip format.
There is a (probably non-viable) case where it might not get initialized
by the function and then potentially used, so set it to NULL to silence
Clang.
Some users of MK_ERROR pass in parameters from a variable called "res",
which is obviously not what they want to do, as that will use this "res"
and not theirs.
Spotted by Clang.
* The if-case was appending to gccBaseFlags after the rest of the file
was done using it, so it was ineffective. Now we set it with the rest
of the baseFlags.
* We already pass no-integrated-as in configure, no need to do it in
MainBuildRules.
* B_USE_BUILTIN_ATOMIC_FUNCTIONS isn't used anymore, so get rid of it.
Now, instead of breaking them up, all settings related to or gleaned
from the compiler are listed first (except for BOOT_CXXFLAGS_...).
No functional change intended.
If one specifies a cross-tools path instead of --build-cross-tools along
with --use-clang, then the specified architecture winds up in the list twice,
as the first test looks for the arch name where only "unknown" exists
(since in the case of cross-tools paths, we delay fetching the arch.)
So we need to move this check to there instead.
This lets clang use our linker and other binutils instead of its own.
Now clang builds produce a working bootloader and get all the way
to the "rocket" icon, at which point userland init fails.
Most of the problems with tree-vrp stemmed from its deletion of null-pointer
checks (see linked commit in the source.) Now, GCC has a flag to control that,
and with it enabled I can boot to the desktop even with tree-vrp enabled.
* When Download window is initially shown, it is correctly
fully onscreen; however, adding a download resizes the
window such that it becomes partially offscreen. Now,
when the frame is resized, reposition the window onscreen
again.
Fixes#12704
The user iframe and associated data that the syscall entry pushes to the
stack directly were causing the stack to be mis-aligned by 8 bytes. Since
we re-aligned %rsp afterwards, for most usecases this wasn't a problem.
However, since we stored the pre-realinged %rsp in %rbp (as we need it to
access the iframe data), this also meant that anything which depended on
%rbp being 16-byte-aligned would run into serious problems.
As it turned out, GCC 7 assumed that %rbp was indeed 16-byte-aligned, and
so optimized certain accesses to use SSE instructions that depended on this
alignment. Since inside any callstack begining with a syscall this was not
the case, a "General Protection Exception" resulted (see #14160 for an example)
at the first usage of such an instruction. I wasn't really sure what was going
on when it first came up, and so "fixed" it by disabling the GCC optimization
that used such instructions. Replacing the -fdisable... with -mstackrealign thus
also "fixes" the problem, as I discovered earlier today, as it forces GCC to
realign the stack in function prologues.
So instead of rounding %rsp down to the nearest aligned address after the
pushes are complete, we offset %rsp by the amount the pushes are not,
thus fixing both %rsp and %rbp in syscall handling routines. This of course
depends on syscall_rsp being already aligned, which it is.
Thanks to PulkoMandy and js for the advice and guidance (and PulkoMandy
for the ASCII art), as this is essentially my first time working with
kernel assembly.
* Using attribute visibility hidden doesn't get applied if a
function returns a non-class pointer type, so the functions
weren't being hidden for gcc4+ builds, resulting in stack
overflows. Using addr_t, which should be the same size as
void* works around this restriction.
This reverts commit c558f9c8fe.
This reverts commit 44f24718b1.
This reverts commit a69cb33030.
This reverts commit 951182620e.
There have been multiple reports that these changes break mounting NTFS partitions
(on all systems, see #14204), and shutting down (on certain systems, see #12405.)
Until they can be fixed, they are being backed out.
- When in non-interactive mode, i.e. saving a crash report, don't
allow the image debug info loader to automatically grab missing but
available info packages. Otherwise we potentially download very large
packages with the user being entirely unaware, i.e. the 200MB debug
information package now present by default for gcc7's libgcc. This
should eventually be made a configurable preference though.
