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>
Previously, a new log-flush thread was created every time there was
an idle transaction. Now we just release a semaphore for an
already-existing thread.
Change-Id: If788dbe17ef8e069ce12aa7b778626d051cce2d0
We already have a dummy spawn_kernel_thread, so this makes sense to add
(and will be required by the next commit.)
Change-Id: Ic46607d46dabc6fd46fcfc0b6f8da0ed9897cfc9
Reviewed-on: https://review.haiku-os.org/c/1650
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This behavior was always used by the semaphore-based MultiLocker,
and it seems a good chunk of code depends on this, so we need
to preserve the behavior.
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>
Since every HWInterface is a MultiLocker, and every BBitmap requires
a server-side BitmapHWInterface, this saves 3 semaphores per BBitmap
instance (as well as a lot of semaphore-related overhead in calling
the kernel so often.)
This function was (or at least now is) severely over-engineered:
it is designed to avoid calling find_thread(NULL) as little
as possible, and use stack addresses to determine if the current
thread is the one holding the write lock.
However, this is unneccessary, as find_thread(NULL) has been
optimized (on x86 and x86_64, at least) to be a single "mov"
from thread-local data, with no syscall. So that is probably
even faster than an integer divide and compare, allowing
this function to be simplified greatly.
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.
Most of these should have been BLocker::InitCheck() anyway.
The one that was actually using the sem (MessageLooper)
should just store the name parameter, which simplifies
things anyway.
Done as a result of a branch where I'm experimenting
with making BLocker not even create a semaphore in
"benaphore" mode.
- Show a lock for encrypted partitions (bitlocker, pgp, safeboot, luks)
- Show icons for boot, shared, virtual or read-only partitions
- Use different colors for boot, bfs, encrypted partitions
- Show partition usage in visual overview (only for mounted volumes)
- Add more infos in the parameter column
- Add columns with free space and block size
Fixes#10098 (as mentionned there, TrueCrypt/DriveEncryption can't be
detected)
Change-Id: I44914bacfabadaec4f862c8816f9575dc9617798
Reviewed-on: https://review.haiku-os.org/c/1399
Reviewed-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Complete working and view of pointing devices(mouse and touchpad).
Resolve some issues.
Added the Jamfile
Change-Id: I4db021cb8c63971e5af60bd254c8b3b588d023e9
Reviewed-on: https://review.haiku-os.org/c/1426
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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>
Now provided in the tnftp package.
Change-Id: I862b1ff98586aa0e5a9418cf26e30b7136140249
Reviewed-on: https://review.haiku-os.org/c/1641
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Only out-bound isochronous transfers are tested right now, but in
theory inbound ones "should" work just fine, too. The frame calculation
has a bunch of TODOs around it, because I'm probably not doing it
entirely correctly...
But hey, I made this commit while listening to some glitchy (audio
only in left channel, strange pops occurring intermittently, but
otherwise it sounds 100% correct) music over my USB audio device!
(I'm willing to blame the above problems on our rather buggy
usb_audio driver.)
* If we fail to stop the endpoint: don't leave things in a valid
but broken state (i.e. the "used" field will get 'leaked', which may
prevent transfers from occurring in the future.)
* Free transfers when cleaning up the endpoint, to avoid memory leaks.
* A few other miscellaneous cleanups.
My work-in-progress isochronous support seems to trigger instances
of the StopEndpoint command either failing or taking longer than
our timeouts allow, so maybe this will improve things enough for things
to work just a bit more.
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>
