We allow teams to clone areas within themselves, but I'm not sure
exactly what use that has. The kernel can of course clone anything
it wants to, still.
Hopefully this will prove substantially less disruptive than the
reverse change last year, as the preceding commits are likely the
only major consumers of this API, rather than a variety of drivers
that need to be individually tested.
It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.
No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)
Sparcv9 runs Openboot in 64 bit mode, which means the cell size is
64bit. Use intptr_t where appropriate to make the open firmware calls
work.
Beware, some values are still 32bit, this matters for example for
of_getprop, if you get 32bits into a 64bit variables it will be in the
MSB of it (big endian only weakness...) and confuse things. See for
example in console.cpp, where the input and output handles are retrieved
as 32bit values. It seems wise to check the expected size when using
of_getprop in these cases, instead of just checking for errors.
Change-Id: Ie72ebc4afe7c6d7602a47478f0bfb6b8247004b8
Reviewed-on: https://review.haiku-os.org/c/1369
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The video mode hook gets passed a menu and an item, but is actually
interested in the submenu pointed by the item and the items inside that.
Don't reuse the passed parameters and instead declare new local
variables.
Change-Id: Id17adde552fac2c248afa78380ff299fb21bc968
Reviewed-on: https://review.haiku-os.org/c/1693
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
No functional change intended, added some copyrights
in the process.
Change-Id: Ic6ebe276bb939c425d65aff1b3b07c7c2e27a33a
Reviewed-on: https://review.haiku-os.org/c/1698
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes#15230.
The comment pretty much explains it. I think needing this means this code could
be redesigned, but I don't know enough yet to make that fix.
It also feels like this whole job system and Command pattern is overly
complicated when good old functions would be fine, certainly for pkgman. But
maybe this is used more heavily in HaikuDepot.
Without this, even installed packages still get an "Install" button.
Fixes#14821.
This was implemented by adding BPackageRoster::IsPackageActive. I decided to
have this take a location since GetActivePackages also did, but as noted in my
TODO comment, I think this is awkward.
It would also be nice to show the user they have a different version of a
particular package, but that would require some changes to IsPackageActive.
Change-Id: Iab0d35eb6b671a17711b0214b15164d296927e5a
Reviewed-on: https://review.haiku-os.org/c/1694
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
* After a bunch of trials, the groupings for VPN and Dial-up
connections look too busy. By putting the "connections"
at the same level as the interfaces things get a bit clearer
and a little more modern.
* Lots of work to do still for "adding / removing" connections.
There was no check for strtoul success or failure (it returns 0 on
failure but that is also a valid conversion result). Detect if endptr
has been advanced instead (meaning there were some parsed characters in
strtoul so the argument at least starts with a number)
Change-Id: Ieefbd57a250ddcdb9362094389151c2a432e4c73
Reviewed-on: https://review.haiku-os.org/c/1683
Reviewed-by: Rene Gollent <rene@gollent.com>
To be upstreamed to FreeBSD?
Change-Id: Ia4389f4964429f80025003f97792b1ecd1097193
Reviewed-on: https://review.haiku-os.org/c/1681
Reviewed-by: Rene Gollent <rene@gollent.com>
We don't ship ftp anymore, and our tput comes from ncurses now.
Change-Id: I80e99b72f5bb16147a234d6d72a277a5035b6e00
Reviewed-on: https://review.haiku-os.org/c/1680
Reviewed-by: Rene Gollent <rene@gollent.com>
This "race prevention" code does not seem to be really hit at all
in practice, at least from testing, so no need to do a full
unlock/lock universally for it.
I'm still not sure why the previous fixes here removed 80% of
the performance benefits of the original change; I need to
investigate that more.
Consider this scenario:
* A userland thread puts its ID into some structure so that it
can be woken up later, sets its wait_status to initiate the
begin of the wait, and then calls _user_block_thread.
* A second thread finishes whatever task the first thread
intended to wait for, reads the ID almost immediately
after it was written, and calls _user_unblock_thread.
* _user_unblock_thread was called so soon that the first
thread is not yet blocked on the _user_block_thread block,
but is instead blocked on e.g. the thread's main mutex.
* The first thread's thread_block() call returns B_OK.
As in this example it was inside mutex_lock, it thinks
that it now owns the mutex.
* But it doesn't own the mutex, and so (until yesterday)
all sorts of mayhem and then a random crash occurs, or
(after yesterday) an assert-failure is tripped that
the thread does not own the mutex it expected to.
The above scenario is not a hypothetical, but is in fact the
exact scenario behind the strange panics in #15211.
The solution is to only have _user_unblock_thread actually
unblock threads that were blocked by _user_block_thread,
so I've introduced a new BLOCK_TYPE to differentiate these.
While I'm at it, remove the BLOCK_TYPE_USER_BASE, which was
never used (and now never will be.) If we want to differentiate
different consumers of _user_block_thread for debugging
purposes, we should use the currently-unused "object"
argument to thread_block, instead of cluttering the
relatively-clean block type debugging code with special
types.
One final note: The race condition which was the case of
this bug does not, in fact, imply a deadlock on the part
of the rw_lock here. The wait_status is protected by the
thread's mutex, which is acquired by both _user_block_thread
and _user_unblock_thread, and so if _user_unblock_thread
succeeds faster than _user_block_thread can initiate
the block, it will just see that wait_status is already
<= 0 and return immediately.
Fixes#15211.
* 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>
This change renders a striped background in the
'barber pole' in HaikuDepot application when it is
idle. This makes the 'barber pole' easier to use
in situations where the space that the UI control
takes up should not be blank. The logic for the
striped background is from the 'drivesetup'
application.
Change-Id: I87791c70b4d1a21d91e661433d6c940ca69ece87
Reviewed-on: https://review.haiku-os.org/c/1674
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This avoids a few potential race conditions mmlr pointed out on
the mailing list. See inline comments.
Change-Id: I605523c1d2683c749751599c417a68a20c70edea
Previously, both the "old" owner and the "new" lock owner set
the lock holder to the "new" lock holder. Now the old owner does
it before calling unblock(), and we check in the lock() functions
that we are indeed the new owner of the lock.
This may affect what the panic is for #15211 and its duplicates:
I have a suspicion that these threads are getting unblocked
when they have no business being unblocked, and this should
catch that condition.
Should (actually) fix#15223 and #15226. After things settle
down a bit, I'll refactor our ConditionVariable constructors
to detect this at compile time instead of creating obscure
KDLs...
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
This way the static functions (used only in KDL) are below
the actual notification methods, which are now all grouped
together in one place.
No functional change.
Since this thread has a very high priority, this causes the whole system
to lock up, making recovery from such a critical condition even more
impossible. Instead use the Warning-level timeout instead (0.3 seconds),
and of course we will be notified via the semaphore if something occurs
we should know about.
I find this handy and in addition it makes the slide show cyclic again,
fixing #10386.
Going the other way might also be useful, but that requires some additions to
the Navigator code first.
This is part of a new diagnostic I've managed to wire up
that finds all instances of "status_t" function return
values being discarded using attribute trickery and some
creative Clang pragmas. As you might guess, the resultant
errors list is absolutely gigantic, and most of them are
ones where the failure condition will never (that we care
about) be hit.
The ones in this commit likely are no-op changes, but
they were low-hanging fruit spotted while reviewing
the larger list. The next commit will bring more
substantial changes.
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>
memcpy with a negative parameter doesn't look like a great idea.
Change-Id: I3d1a8c224bd288784f068086652a84b2b75fcea8
Reviewed-on: https://review.haiku-os.org/c/1671
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
