Searched +hist:1 +hist:bc7045f (Results 1 - 25 of 29) sorted by path

12

/haiku/headers/os/kernel/
H A DOS.hdiff f66d2b46 Wed Jul 26 14:51:38 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> kernel: Add event queue implementation to wait for objects efficiently.

Based on hamishm's original patch from 2015, but heavily modified,
refactored, and reworked.

From the original commit message:

> When an object is deleted, a B_EVENT_INVALID event is delivered,
> and the object is unregistered from the queue.
>
> The special event flag B_EVENT_ONE_SHOT can be passed in when adding
> an object so that the object is automatically unregistered when an
> event is delivered.

Modifications to the original change include:

* Removed the public interface (syscalls remain private for the moment)

* Event list queueing/dequeueing almost entirely rewritten, including:
- Clear events field when dequeueing.

- Have B_EVENT_QUEUED actually indicate whether the event has been
appended to the linked list (or not), based around lock state.
The previous logic was prone to races and double-insertions.

- "Modify" is now just "Deselect + Select" performed at once;
previously it could cause use-after-frees.

- Unlock for deselect only once at the end of dequeue.

- Handle INVALID events still in the queue upon destruction,
fixing memory leaks.

* Deduplified code with wait_for_objects.

* Use of C++ virtual dispatch instead of C-style enum + function calls,
and BReferenceable plus destructors for teardown.

* Removed select/modify/delete flags. Select/Modify are now the same
operation on the syscall interface, and "Delete" is done when 0
is passed for "events". Additionally, the events selected can be fetched
by passing -1 for "events".

* Implemented level-triggered mode.

* Use of BStackOrHeapArray and other convenience routines in syscalls.

Change-Id: I1d2f094fd981c95215a59adbc087523c7bbbe40b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6745
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
diff 9a50e01e Wed Nov 15 10:28:04 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> set_real_time_clock: Change parameter from uint32 to uint64.

This should have been done along with the time_t change, but I forgot
to check this then.

Technically this breaks ABI against BeOS, but:
1. BeOS used an int32, so we'd already slightly broken ABI here
2. Only one thing at HaikuArchives (VMwareAddons) and one recipe at HaikuPorts
(samba) uses this function at all.

If it turns out some critical BeOS app uses this, then I guess we can enclose
GCC2 guards around it, but since I can't find any evidence of that, I'm
pushing it without them for now.
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c2d7d3a Thu Jun 16 11:58:24 MDT 2011 Ingo Weinhold <ingo_weinhold@gmx.de> Fixed x86_64 handling by the build system.

* Map build variables HOST_CPU and HOST_ARCH to x86_64, if it they are
* x86 and
64 bit and define the __x86_64__ C macro instead of __INTEL__ in that
case.
* <OS.h>: Also handle __x86_64__.
diff 2c1e463c Wed Nov 05 11:11:58 MST 2008 Axel Dörfler <axeld@pinc-software.de> * Removed B_{MIN|MAX}_PRIORITY from OS.h - they were never really intended
as public defines. They are now called THREAD_{MIN|MAX}_SET_PRIORITY to
better reflect what they are for. Minimum priority is now 1, ie. you no
longer can set another thread to the idle priority. This fixes part of
ticket #2959.
* set_thread_priority() will no longer allow to change the priority of the
idle thread to something else. This fixes the rest of ticket #2959.
* Automatic whitespace cleanup in OS.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28521 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff b4092833 Sat Jun 21 15:48:18 MDT 2008 François Revol <revol@free.fr> Set max cpu count to 1 for ARM. Anyone knows a real SMP platform using it ?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26069 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1e8adb7d Thu Aug 24 04:33:50 MDT 2006 Jérôme Duval <korli@users.berlios.de> added core and core 2 ids


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18603 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff b2c5594f Mon May 29 18:18:50 MDT 2006 Axel Dörfler <axeld@pinc-software.de> B_SYSTEM_TEAM is now 1 under Haiku which refers to the real kernel.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17645 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 9235adf7 Sun Oct 30 11:26:41 MST 2005 Axel Dörfler <axeld@pinc-software.de> The cpuid "extended features" in function 1/%ecx aren't Intel only anymore - my
AMD docs were not up to date. Thanks to Herve for the note.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14578 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/headers/private/kernel/arch/
H A Dsystem_info.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/headers/private/shared/
H A Dcpu_type.hdiff 8a9e1e0d Sun Dec 31 14:10:55 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> Removal of non-Haiku target platform logic from build system (part 1.)

Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.

This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1e8adb7d Thu Aug 24 04:33:50 MDT 2006 Jérôme Duval <korli@users.berlios.de> added core and core 2 ids


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18603 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1e8adb7d892e8082415b3d0d632831896a6b4210 Thu Aug 24 04:33:50 MDT 2006 Jérôme Duval <korli@users.berlios.de> added core and core 2 ids


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18603 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/headers/private/system/
H A Dsyscalls.hdiff f66d2b46 Wed Jul 26 14:51:38 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> kernel: Add event queue implementation to wait for objects efficiently.

Based on hamishm's original patch from 2015, but heavily modified,
refactored, and reworked.

From the original commit message:

> When an object is deleted, a B_EVENT_INVALID event is delivered,
> and the object is unregistered from the queue.
>
> The special event flag B_EVENT_ONE_SHOT can be passed in when adding
> an object so that the object is automatically unregistered when an
> event is delivered.

Modifications to the original change include:

* Removed the public interface (syscalls remain private for the moment)

* Event list queueing/dequeueing almost entirely rewritten, including:
- Clear events field when dequeueing.

- Have B_EVENT_QUEUED actually indicate whether the event has been
appended to the linked list (or not), based around lock state.
The previous logic was prone to races and double-insertions.

- "Modify" is now just "Deselect + Select" performed at once;
previously it could cause use-after-frees.

- Unlock for deselect only once at the end of dequeue.

- Handle INVALID events still in the queue upon destruction,
fixing memory leaks.

* Deduplified code with wait_for_objects.

* Use of C++ virtual dispatch instead of C-style enum + function calls,
and BReferenceable plus destructors for teardown.

* Removed select/modify/delete flags. Select/Modify are now the same
operation on the syscall interface, and "Delete" is done when 0
is passed for "events". Additionally, the events selected can be fetched
by passing -1 for "events".

* Implemented level-triggered mode.

* Use of BStackOrHeapArray and other convenience routines in syscalls.

Change-Id: I1d2f094fd981c95215a59adbc087523c7bbbe40b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6745
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
diff 6f3f29c7 Tue Jun 06 21:30:15 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 6f3f29c7 Tue Jun 06 21:30:15 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 6f3f29c7 Tue Jun 06 21:30:15 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A Dsystem_info.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/aboutsystem/
H A DAboutSystem.cppdiff 1d5de1d8 Tue Oct 26 15:54:58 MDT 2021 Augustin Cavalier <waddlesplash@gmail.com> Remove firmware licenses that now are in their own packages.
diff 1d5b36ce Sat Jan 03 10:41:21 MST 2015 luroh <lurohh@gmail.com> Clean up FreeType outsourcing leftovers

- Remove obsolete FreeType docs
- Remove obsolete FreeType license
- Update FreeType license and copyrights in AboutSystem

Signed-off-by: Adrien Destugues <pulkomandy@gmail.com>

Fixes #11697
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1f67610d Fri Aug 02 20:14:02 MDT 2013 Rene Gollent <anevilyak@gmail.com> Move Alex Smith to active maintainers list.
diff 1f92d747 Fri Nov 25 07:34:28 MST 2011 Humdinger <humdingerb@gmail.com> Removed duplicate license for GLU. Thanks Rimas.
diff 27997edc Sun Jan 09 14:03:37 MST 2011 Siarzhuk Zharski <zharik@gmx.li> 1) Add Google Code-In student Michael Bulash into:
- list of translators for his work on complete Belarusian translation;
- list of contributors for his work on internationalization of LaunchBox,
PowerStatus and ProcessController applications and following preflets:
DataTranslations, E-Mail, Notifications, Screen, ScreenSaver, Time.
2) Corrected the name of Russian translator Rodastahm Islamov on his request.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40185 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1d6c7b6c Tue Aug 17 12:43:41 MDT 2010 Alex Wilson <yourpalal2@gmail.com> Big change deriving BLayout from BLayoutItem, and allowing viewless BLayouts.
a few highlights:
* BLayout now derives publicly from BLayoutItem
* Added BAbstractLayout class, which our layouts now derive from
* updated layout builders to avoid creating views when they don't need to
* updated layout classes
* updated AboutSystem to fix a little regression
* more details on #6407
* please tell me about any regressions, I've tried to find them all, but some
may have slipped by.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38207 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1e9ba7f2 Sun Dec 20 09:20:58 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> Patch by Matt Madia with small modifications by myself: Read and display the
"SourceURL" fields in optional package descriptions.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34725 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1e752e59 Thu Dec 03 14:42:35 MST 2009 Adrien Destugues <pulkomandy@pulkomandy.ath.cx> Added translation contributors to AboutSystem. I was not sure how to present the "languages" subtitles, feel free to improve.
I hope I didn't forgot someone and got everything right. Thanks to you all :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34478 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/apps/activitymonitor/
H A DDataSource.cppdiff 1f5daef0 Tue Feb 27 15:06:15 MST 2024 Emir SARI <bitigchi@me.com> ActivityMonitor: use BNumberFormat for i18n

Change-Id: I3179f84cbaee25624c2f4a7b092a28b5281a5f16
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7480
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1cac1beb Sat Jul 13 11:32:55 MDT 2013 Philippe Saint-Pierre <stpere@gmail.com> ActivityMonitor: use new units KiB/MiB for display (#5378)
diff b190a54c Thu Nov 22 06:20:57 MST 2012 Ithamar R. Adema <ithamar@upgrade-android.com> activitymonitor: remove B_MAX_CPU_COUNT reference

It has no use, since we don't know its value and the list of colors
might be longer (for example, for ARM currently B_MAX_CPU_COUNT is
only 1). The modula operator later on makes sure we keep within the
bounds of the kColors array anyway.
diff ee872034 Sun Nov 14 04:29:50 MST 2010 Axel Dörfler <axeld@pinc-software.de> * Start numbering the CPUs with 1 instead of 0. This closes ticket #6816.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39426 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1cac1bebcb957e4f7edea51b1de1976a4ec37bc6 Sat Jul 13 11:32:55 MDT 2013 Philippe Saint-Pierre <stpere@gmail.com> ActivityMonitor: use new units KiB/MiB for display (#5378)
diff b190a54c4046dd230f5ae19ad4fa86cf3d1dc4fc Thu Nov 22 06:20:57 MST 2012 Ithamar R. Adema <ithamar@upgrade-android.com> activitymonitor: remove B_MAX_CPU_COUNT reference

It has no use, since we don't know its value and the list of colors
might be longer (for example, for ARM currently B_MAX_CPU_COUNT is
only 1). The modula operator later on makes sure we keep within the
bounds of the kColors array anyway.
diff ee87203426eeaa36e41a8f33d417388ae32543ca Sun Nov 14 04:29:50 MST 2010 Axel Dörfler <axeld@pinc-software.de> * Start numbering the CPUs with 1 instead of 0. This closes ticket #6816.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39426 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DSystemInfo.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/diskprobe/
H A DTypeEditors.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/packageinstaller/
H A DPackageInfo.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/processcontroller/
H A DMemoryBarMenu.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c292f7e Fri Jul 19 18:50:36 MDT 2013 Rene Gollent <anevilyak@gmail.com> ProcessController: Fix memory calculations.

On systems with > 4GB of memory, the calculations would overflow,
leading to the memory bars being drawn incorrectly.
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c292f7eb4e1aaebdb8ea3d860ffb1f4963821ba Fri Jul 19 18:50:36 MDT 2013 Rene Gollent <anevilyak@gmail.com> ProcessController: Fix memory calculations.

On systems with > 4GB of memory, the calculations would overflow,
leading to the memory bars being drawn incorrectly.
H A DMemoryBarMenu.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DProcessController.cppdiff c2e78713 Wed Jan 13 05:00:51 MST 2021 Adrien Destugues <adrien.destugues@opensource.viveris.fr> ProcessController: reintroduce the static scaling mode.

There is a very good reason to have this: for low number of cores, the
default computation makes stupidly large bars.

I had tested my changes with various number of cores (1, 2, 3, 4, 8, 16)
in QEMU to make sure it looked correct in all cases. I don't understand
why kallisti5 reintroduced broken code.

This reverts commit b18298348af33f990b51d66cf21652b0a4520317.
This reverts commit b1b6769b6f040f077544d7884ca5a7c4fbb7af27.
diff b1829834 Sun Jan 10 18:06:31 MST 2021 Alexander von Gluck IV <kallisti5@unixzen.com> ProcessController: Just toss static scaling mode all together

* It was making things confusing and honestly the dynamic
calculation code does a pretty good job.
* Just make sure we scale the scale the CPU bars with a
multipler that makes sense for a minimum width.
* This should give us a good baseline. Tested 1 to 32 cpus

Change-Id: If41c73e68b2de2b39196013af13e6c0ffdbe6489
diff b1b6769b Sun Jan 10 16:53:08 MST 2021 Alexander von Gluck IV <kallisti5@unixzen.com> ProcessController: Fix static scaling mode after hrev54874

* We saw a "big" cpu bar on 1 core.
* This was because adding 8 to the static "15" width
resulted in the static CPU sizing code getting disabled
* Converting this to 4 just completely disabled the static
scaling code and made dynamic always enabled

Change-Id: Ida8c718c0d0a2fcf72aedbf525daad040d5b3678
diff c38dea9e Fri Jan 08 23:48:46 MST 2021 Alexander von Gluck IV <kallisti5@unixzen.com> processcontroller: Scale up width on high core counts

* 4 cores or less, use static table. More make view larger.
* 16 cores or less, 2px CPU bars
* More than 16 cores, 1px CPU bars
* Tested through 128 cores in qemu

Change-Id: I5fb460e7ee5848d0395b109acc602e86f4d5bbd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3616
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c292f7e Fri Jul 19 18:50:36 MDT 2013 Rene Gollent <anevilyak@gmail.com> ProcessController: Fix memory calculations.

On systems with > 4GB of memory, the calculations would overflow,
leading to the memory bars being drawn incorrectly.
diff 3440db0c Sat Feb 19 06:32:39 MST 2011 Siarzhuk Zharski <zharik@gmx.li> Yet another localization patch made by Jorma Karvonen.
Fixes #7238

Notes on patch:
1) Localization of internal Deskbar item name and kClassName rejected;

Additional fixes by S.Zharski:
1) BLocker's internal name localization removed;
2) A bit more safe snprintf used instead of sprintf;
3) Localization of field names in 'PrTh' message removed;
4) Localization of calling "db" debugger removed. The thread debugging command
"db %d" replaced with "gdb -pid=%d".



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40558 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 3440db0c Sat Feb 19 06:32:39 MST 2011 Siarzhuk Zharski <zharik@gmx.li> Yet another localization patch made by Jorma Karvonen.
Fixes #7238

Notes on patch:
1) Localization of internal Deskbar item name and kClassName rejected;

Additional fixes by S.Zharski:
1) BLocker's internal name localization removed;
2) A bit more safe snprintf used instead of sprintf;
3) Localization of field names in 'PrTh' message removed;
4) Localization of calling "db" debugger removed. The thread debugging command
"db %d" replaced with "gdb -pid=%d".



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40558 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1d1b0d06 Fri Aug 31 18:31:19 MDT 2007 Ingo Weinhold <ingo_weinhold@gmx.de> Made ProcessController's "Debug Thread" feature work under Haiku. We
don't have a "db" command (we could probably add a small shell script
that invokes gdb in a Terminal), but just as BeOS we have
debug_thread(), which does exactly that -- throwing a thread into the
debugger. It (at least Haiku's version, not sure about BeOS's) also
interrupts system calls, which makes the semaphore releasing hack
superfluous.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22132 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DProcessController.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DTeamBarMenuItem.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/pulse/
H A DDeskbarPulseView.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DNormalPulseView.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DPulseApp.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DPulseApp.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DPulseView.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/bin/
H A DJamfilediff 1e60bdea Sat Mar 30 13:01:03 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> Remove all invocations of SetSubDirSupportedPlatformsBeOSCompatible.
diff 8a9e1e0d Sun Dec 31 14:10:55 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> Removal of non-Haiku target platform logic from build system (part 1.)

Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.

This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
diff 1f56c11b Wed Jun 10 03:26:51 MDT 2015 Jérôme Duval <jerome.duval@gmail.com> gzip: use the outsourced packages.

* remove gzip Jamfile from the build and gzip sources from the tree.
diff 1a8c6944 Wed Apr 16 16:00:40 MDT 2014 Jérôme Duval <jerome.duval@gmail.com> less: use the outsourced packages.

* added packages for x86 and x86_64.
diff 94c2eb20 Sat Dec 28 01:58:27 MST 2013 François Revol <revol@free.fr> Revert "Add getconf(1) from FreeBSD r259958"

This reverts commit 5a39a9feac1ed9903c099825122f0628f7944fca.
diff 5a39a9fe Fri Dec 27 11:42:26 MST 2013 François Revol <revol@free.fr> Add getconf(1) from FreeBSD r259958

This one lacks -a but is simpler to port than the (e)glibc one,
and should be way enough for usage patterns like counting CPUs,
cf. https://gist.github.com/jj1bdx/5746298

TODO: Handle message files?
TODO: Install manpage?
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff b0944c78 Thu Aug 01 00:51:16 MDT 2013 Ingo Weinhold <ingo_weinhold@gmx.de> More work towards hybrid support

* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).
diff 1f5facdb Sat Apr 28 01:59:52 MDT 2012 Jerome Duval <jerome.duval@gmail.com> sysinfo: switch to c++
H A Dsysinfo.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1f5facdb Sat Apr 28 01:59:52 MDT 2012 Jerome Duval <jerome.duval@gmail.com> sysinfo: switch to c++
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
1f5facdbe7e25dc9618ec413eda01adf82d763f2 Sat Apr 28 01:59:52 MDT 2012 Jerome Duval <jerome.duval@gmail.com> sysinfo: switch to c++
/haiku/src/kits/tracker/
H A DTaskLoop.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/servers/app/drawing/Painter/
H A DPainter.cppdiff 1f357f79 Fri Feb 04 12:29:23 MST 2022 Máximo Castañeda <antiswen@yahoo.es> Painter: sync renderer color

SetDrawState sets the pattern directly and then calls the member
functions to update colors. As SetHighColor does not update the renderers
if color does not change, that means we lose sync in some corner cases.

Change-Id: I5f8771baa58643c559df243dcc1603983941faee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4930
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 0ccd1db1 Wed Jan 13 15:50:31 MST 2016 Julian Harnath <julian.harnath@rwth-aachen.de> app_server: fix lines which are pixel dots, in layers

* Painter::StrokeLine() has an optimization for lines which are
single pixel dots, i.e. identical start and end point and pen
size 1: it sets the pixel directly in the buffer, completely
bypassing the AGG base renderer.

This is a problem when inside a layer since this also bypasses
the low-level offset in the base renderer (which moves drawing
coordinates into the layer bitmap), causing an out-of-bounds
access.

* Fixes #12587
diff 1e625a2b Tue Mar 11 15:11:08 MDT 2014 Stephan Aßmus <superstippi@gmx.de> app_server: Removed duplicate line of code...

for setting the filling rule. There are only two different rasterizers.
diff 63a30a47 Tue Feb 04 15:52:32 MST 2014 Stephan Aßmus <superstippi@gmx.de> Implemented using the transformation in Painter (incomplete)

* Also removed wonky BeOS rendering of stroked round rects and ellipses.
Nobody would expect it to work like this. This affects stroked round rects
and ellipsis with a pensize greater than 1.
* Refactored common code from _StrokePath() and _FillPath().
* _StrokePath() returned a curious bounding box that didn't take into
acount the miter width. Now the bounding box is computed from the actual
stroke conversion of the path.
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff a17be100 Sat Jun 03 08:14:59 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * "divisions" could be lower than 1. This fixes bug #510.
* Moved expensive computation out of the max_c() macro.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17709 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1fce337f Fri Dec 30 16:41:57 MST 2005 Stephan Aßmus <superstippi@gmx.de> cleaned up the code using templates and added optimized version for CMAP8 bitmaps and B_OP_OVER (to benefit Tracker)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15760 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1f0a4ee8 Tue Dec 20 15:39:54 MST 2005 Stephan Aßmus <superstippi@gmx.de> removed unused stuff from Painter and DrawingEngine, fixed the deadlock when trying to use the (20 times faster) DrawingEngine version of StringWidth, the font is now usually ignored when taking on a DrawState in Painter... should add a little speed overall

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15628 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff ac167e6e Sat May 21 18:12:56 MDT 2005 Stephan Aßmus <superstippi@gmx.de> Various fixes and efficiency improvements to the drawing backend. Among other stuff, stroked lines with a width greater than 1 have anti-aliased butts now. There are some bugs left regarding text rendering.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12761 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/arch/x86/
H A Darch_system_info.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info

Completed in 562 milliseconds

12