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
