* It's safe to assume that if the file is shorter than
the provided header, things will go poorly.
* Avoids a random vauge ReadBuffer error.
* This doesn't fix#15230, but makes the issue clearer.
Change-Id: I3471e6de384a0c9be94049ad891c01be980f7846
Reviewed-on: https://review.haiku-os.org/c/1679
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Before this commit, *all* ConditionVariable operations (yes, all;
even Wait, Notify, etc.) went through a single spinlock, that also
protected the sConditionVariableHash. This obviously does not scale
so well with core count, to say the least!
With this commit, we add spinlocks to each Variable and Entry.
This makes locking somewhat more complicated (and nuanced; see
inline comment), but the trade-off seems completely worth it:
(compile HaikuDepot in VMware, 2 cores)
before
real 1m20.219s
user 1m5.619s
sys 0m40.724s
after
real 1m12.667s
user 0m57.684s
sys 0m37.251s
The more cores there are, the more of an optimization this will
likely prove to be. But 10%-across-the-board is not bad to say
the least.
Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a
Also do some cleanup in private headers, I can't imagine why the build
libraries would need this function.
Change-Id: Ib08810b6efe4738dad596a735d741582a3781b28
Reviewed-on: https://review.haiku-os.org/c/1670
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
In CodyCam, we attempt to cast the result of this macro to const char*.
However, the ternary operator has lower priority than the cast so it
doesn't work as expected.
Add some protective parentheses here.
Change-Id: I5e9875187cec67b9534b1bbe58d82217c6cd5524
Reviewed-on: https://review.haiku-os.org/c/1667
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unless __STRICT_ANSI__ is defined (as it is when running the compiler in
--std=c89 or --std=c99, but not when running it without any specific
args), we can enable these by default and behave like most other
systems. I don't know why no one has done this yet despite suggesting it
multiple times and people prefer to #define _BSD_SOURCE manually
everywhere.
Remove all places in our Jamfiles and sources where it had been defined.
_DEFAULT_SOURCE is now enabled by default for all sources of Haiku, since we
let the compiler use GNU extensions (no strict C standard specified on
command line)
Use _DEFAULT_SOURCE as the define name to match current versions of
glibc. Enable it if _BSD_SOURCE is #defined in compiler flags, for
backward compatibility.
Change-Id: I6db04da5f6db437723cdfba3478f5094a69d7727
Reviewed-on: https://review.haiku-os.org/c/1633
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
I assume the intent was the same as in other similar functions above.
Change-Id: I887cd73d846680a5a5ec5c90f678ad4b12122eb3
Reviewed-on: https://review.haiku-os.org/c/1655
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
My upcoming changes to use our "futexes" instead of semaphores
will obviously not work on non-Haiku platforms, so we now
need a copy of this class in libbe_build.
This defines the number of bits in a byte and is used in tnftpd.
Once this is merged, some patches to tnftpd can be removed.
Change-Id: Ie2d0c61ce1371daeeb8549281f4210147fb77197
Reviewed-on: https://review.haiku-os.org/c/1642
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's used by both Tracker and Codycam and others might find it useful.
Change-Id: I585d3a1bdc7f8fce7d36bedf6867464cd541ba2e
Reviewed-on: https://review.haiku-os.org/c/1637
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, it identified all Zen CPUs as Ryzen 7. Since the model
and stepping information consist of microarchitecture information
and don't carry the model number, use the parse_amd based name,
which will remove any unnecessary details from the returned name.
Fixes#15153.
Change-Id: I1a20bf35a60b2fdd20d4cc90ec2dd95fd0e6439d
Reviewed-on: https://review.haiku-os.org/c/1634
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Discovered this while working on VLC, checked with other online sources too.
Change-Id: I114c20babda0ff0e90d0eeee299d8483700166bd
Reviewed-on: https://review.haiku-os.org/c/1628
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Even on 64bit CPUs it's a 32bit register.
Change-Id: I9a4de6eec225de19a90d70fae1382b662e530629
Reviewed-on: https://review.haiku-os.org/c/1625
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
B_OS_NAME_LENGTH is 32, char* is 8 (on x64), and this structure
has quite a lot of pointers in it so it is not like we really
needed to save those 24 bytes. Hitting malloc() in here is not
so great, especially because we usually have B_DONT_LOCK_KERNEL_SPACE
turned on, so just inline and avoid it.
Change-Id: I5c94955324cfda08972895826b61748c3b69096a
The idea was that the Media Extractor could wrap the original source
given by BMediaTrack, but all operations on the data go through
MediaExtractor anyway.
We could probably move ownership of the BDataIO completely into
MediaExtractor instead.
Change-Id: I846b34b543fb983e60f6adf86cb17e835303267b
Reviewed-on: https://review.haiku-os.org/c/1587
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
The sparc openboot implementation can run executables in the a.out
format. We used to generate these using objcopy, but this does not work
anymore as binutils is deprecating a.out format support.
- Import elf2aout from FreeBSD
- Add some missing bits to our elf.h and have a copy of it in the build
headers so it can be used to build elf2aout for the host platform
(tested for Linux)
- Use it to generate the sparc haiku_loader
- Adjust the bootloader linker script to have two "program headers": one
that is not loadable and contains the ELF headers, and the second one
that is loadable and contains the actual code and data. Unlike
objcopy, elf2aout relies only on the program headers to know what to
put in its output file (sections are ignored), so this is required
otherwise we end up with the ELF header nested inside the a.out file,
and everything offset from the expected load address as a result.
Confirmed that this allows to build the loader and run it as far as
before, so I'm back to needing to implement some MMU support now.
FreeBSD commit: 7551d83c353e040b32c6ac205e577dbc5f2c8955
Change-Id: I90b48e578fa7f148aeddd8c5998fdddc5cfa73fa
Reviewed-on: https://review.haiku-os.org/c/1557
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
If the buildbots were working, I would have been informed of this
about an hour after I committed it last night. But it seems they aren't.
Maybe kallisti5 will have some more incentive to work on that?
Cleans up some lock/get/unlock sequences, and makes it possible
for external consumers to get team structs (which will be necessary
for permissions checks.)
* Now matches the rest of the architectures.
Change-Id: I6699e0c8f729923770f136f2c9599185a685336a
Reviewed-on: https://review.haiku-os.org/c/1527
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
The previous hack, which as the comment (and __MWERKS__) implies
dates all the way back to the Be era, finally broke: int32 is "int"
on non-x86, not "long", and so this generated an undefined symbol
error on ARM.
The best solution seems to be to make StartMenuBar merely protected,
and then make a subclass where it is fully public to call it.
This is a lot less fragile (and much less ugly.)
Change-Id: I0519d0d9eeb1cc4523d0c6dd4fdfe8688ed1092c
Reviewed-on: https://review.haiku-os.org/c/1516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Remove a currently unused copy of it from HaikuDepot.
Change-Id: Idb97fae8e7190da6bc1049b3c1f1df929ea91bab
Reviewed-on: https://review.haiku-os.org/c/1506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Their copy constructors are exactly what GCC would generate,
but we can't remove them because doing so would make them
trivially copyable, and so they would be passed in registers
on x86_64, an ABI breakage.
So instead we have to add explicit casts to void* here.
A lot of these classes are not *technically* "trivially copyable"
for one reason or another, but in all of these cases it seems
OK to me to use memcpy/memset on them. Adding a cast to void*
tells GCC that "I know what I'm doing here" and shuts up the
warning.
These worked in identical fashion to what the default copy
constructors would be, but their mere presence marks the class
as being "non-trivially copyable," which means that memcpy'ing
it is now a -Werror on GCC 8.
We have to be careful when making this change, though: classes
which *are* trivially copyable can be passed inside registers
on x86_64, so changes like these break ABI in a dangerous way.
These classes is private, so it should not be a problem, but
for other classes (e.g. BRect, BPoint) we cannot fix them
properly right now.
should help for ports.
Change-Id: Id504bdb79cb68db4b615f58848e0e1a86ced8d2b
Reviewed-on: https://review.haiku-os.org/c/1467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
add-ons" is set.
Confirmed to fix#14361. It is finally possible to un-brick an install
with a bad system library in non-packaged without having to use another
install to do so.
Change-Id: Iafea7821f02cb34e77c766b1f97d1c19206b1081
Reviewed-on: https://review.haiku-os.org/c/1452
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
This allows cpu_type.h to be used in C-based software,
with the get_cpu_*() functions all accessible via C as well
as C++ code.
Tested changes with sysinfo, AboutHaiku and Pulse.
Change-Id: Ide87d8e3f2ba5f0f1890f385b1ac90c677bcc274
Reviewed-on: https://review.haiku-os.org/c/1453
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
app_server just passes the add-on path around.
Maybe we should make sure the add-on can be loaded when setting it.
Change-Id: I3acd3299782a22c1666bd5435dbf3d8053e359fa
Reviewed-on: https://review.haiku-os.org/c/1430
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
* Oops, there's a standard for these. Stick to the standard.
* Add a few that could be useful someday.
* Mention iana spec.
Change-Id: I4cf75e8c1e4b25f65d10921c7075fbd53f44e14e
Copied from PPC with the hooks for Apple hardware removed.
To be completed with the actual PCI bus implementation for Sun machines.
This is where we start doing machine specific stuff, apparently.
Change-Id: I06af4de9621e9d40593d153642478d928083e49a
Reviewed-on: https://review.haiku-os.org/c/1364
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* I added this early on, but to be honest, any interesting
workstation class hardware would be riscv64.
* Since riscv32 is mostly embedded or low power, just drop.
Change-Id: Id36274c882c46e766268f2ab53eb1bd5f95227be
Reviewed-on: https://review.haiku-os.org/c/1352
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
By default, all targets support the "haiku" platform, and we no longer
support building for BeOS, Dan0, Zeta, or other BeOS-compatible targets,
so this is no longer needed.
Also remove all references to the non-Haiku compatible platforms, and
change all BEOS_COMPATIBLE checks to HAIKU_COMPATIBLE. Removal of
all SetSubDirSupportedPlatformsBeOSCompatible invocations
will be in the next commit.
Declare and use the correct registers to define a stack frame.
Change-Id: Ice3ba8f8715313a715f6b1cb553a6883541f5cc4
Reviewed-on: https://review.haiku-os.org/c/1327
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Kernel is 64 bit, and we won't need a 32bit load base.
Change-Id: I729bab01c8f71083002db061e153b0e5052b9a1c
Reviewed-on: https://review.haiku-os.org/c/1326
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* firewire and freebsd_network expect the macros come from
sys/param.h, as this is one of the places FreeBSD defines them
* All others are Haiku-native and can use Be-style macros.
Fixes the build breakage caused by PulkoMandy's recent commit.
Remove these from ByteOrder.h now also, as per POSIX they should
come from netinet/in.h.
This is a small source compatibility breakage, but it will only
affect a small portion of non-POSIX, partially-Be applications.
If this triggers, it means something is using the "build" errors while
the build system thinks it is not, which is always an error. Nothing
triggers this at present, but some subtle bugs in the build system
a while back would have been caught by this.
Add a platform cleanup hook before starting the kernel. The openfirmware
and PXE loaders clean up their network stack there, while the other
loaders currently do nothing.
This closes ticket #6166
Change-Id: I34765892dfd9b2310c6af97c9ff7d414afae49e5
Reviewed-on: https://review.haiku-os.org/c/50
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Ia2a86d8814d06950ea2d2d19d966c642d26f81d6
Reviewed-on: https://review.haiku-os.org/c/1302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
A bit of an explanation for these weirdly named functions:
LatestActivePackageInfos() returns the packages on the system that are
both installed and fully set up. When packages are in the middle of being
installed, LatestInactivePackageInfos() shows the packages in the process
of being installed. Once the installation process is done,
LatestInactivePackageInfos() returns nothing. If there are packages that
can't be fully activated without a reboot, CurrentlyActivePackageInfos()
will return the same information as LatestActivePackageInfos(), or if
everything has been installed and activated, it will return no packages.
Change-Id: Ia1814a5abda6d815c46e0b46dc812b4e7af81de3
Reviewed-on: https://review.haiku-os.org/c/1129
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Add various stubs to fix undefined references. No implementation for
anything yet.
Change-Id: I2d398bc2369d099e3a35f0713058d6a5edc6801d
Reviewed-on: https://review.haiku-os.org/c/1138
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This behaves mostly like a pointer, but pointer maths works in bytes,
not the native object size.
It avoids casting to char* and back when doing byte-based pointer math,
making the code easier to read.
Change-Id: I6a8681a398345f0c7d419a2cfe7244d972ffa62f
Reviewed-on: https://review.haiku-os.org/c/1086
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
non standard extension, but widely available to obtain attributes for a thread.
also provides an alias for pthread_getattr_np which is the bsd equivalent.
Change-Id: I26ef8245ed2537186f48c8b8bdf3e42b03e70892
Reviewed-on: https://review.haiku-os.org/c/1172
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
These are simple structs, so hopefully GCC8 will be OK with us
memsetting them. We can't use the standard = {} route because
GCC2 does not support that.
Initialize each class members instead of memset()
for clearing PackageInfoAttributeValue.
Pointed out by gcc8.
Change-Id: I8bdb328e2271e49e840b1294dba9cca544805e72
Reviewed-on: https://review.haiku-os.org/c/1114
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add empty implementation of timer, elf, vm, debugger support, to let the
kernel link.
Also add the kernel linker script.
Change-Id: If0795fa6554aea3df1ee544c25cc4832634ffd78
Reviewed-on: https://review.haiku-os.org/c/1108
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous commit adding these was merged very quickly, so here's one
more...
Change-Id: I23c424db7631db1f0ec48e2d0ae47c8409ae6af2
Reviewed-on: https://review.haiku-os.org/c/1088
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
During the compilation of LLVM version 8, the build failed because it depends
on a constant in this file. In hrev49042 all BSD headers were feature-gated by
_BSD_SOURCE. This is not done (for this file) in glibc and (obviously) not in
BSD's libc.
Since this is not common practise, I would propose removing the feature gate
for this header file, as it would mean that we would have to upstream patches
for ports of other software that depends on the availability of these
constants.
Change-Id: I486f0c2e87eff489ce92d03589a6299ef1be6ca5
Reviewed-on: https://review.haiku-os.org/c/1144
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
