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>
