This includes changes to support the 8188EE device, as well as a
number of critical bugfixes to 8192EE devices, which should make
the driver much more stable and reliable overall.
This driver was completely rewritten and merged with its USB counterpart
in FreeBSD 12. I've imported the USB code, even though it's not compiled
in at all, because it's more than likely I'll get around to USB WiFi support
before FreeBSD 13 comes...
Untested, because I don't have one of these PCI devices.
Yes, this is kind of hacky to put the printer driver as a special case
in here, but we already do this for the Preview driver, and IPP's
printer detection is pretty broken, whereas adding a printer URL manually
seems to still work.
Works around #12702.
It seems some controllers are assigned "invalid" interrupt lines under
the expectation they will be allocated an MSI. So, don't reject
these devices for having an invalid interrupt line until after
we have tried to allocate an MSI for them.
Should fix#14792.
Not used and largely untouched since 2005. FontSelectionView
supersedes FontMenu, and MenuView's options were merged elsewhere
(e.g. Alt/Ctrl swapping now lives in Keymap.)
Now that HAIKU_TOP is a relative path, nearly all paths Jam actually
has to deal with will never contain spaces, so this is now feasible.
Only one issue remains after this commit (namely, setting
HOST_BUILD_COMPATIBILITY_LIB_DIR.)
As Jam prints the entire erring command on failure, including this if-test
in the command itself makes the output somewhat difficult to decipher.
So instead we use two separate rules based on whether or not NO_DOWNLOADS
is set or not.
On a dual-core system with no other applications but the standard ones
running, my standard "compile HaikuDepot with hot disk cache" benchmark
shows a consistent ~5% improvement after this patch (~33.7s -> ~31.9s sys).
On systems with higher core and thread counts, these numbers are probably
very much larger (I'd imagine it could be up to even 10 or 15%.)
Change-Id: I5df2a075bae7c71b84c6fcd33ead60df8e844757
Reviewed-on: https://review.haiku-os.org/c/861
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This was left unimplemented since the dawn of Haiku; but it's so rarely
used nobody seems to have noticed. I've taken care to leave it optimized
for the current thread case.
Change-Id: Ib028a37963b2da6d0ca9b4dbd5a5f4a74ecf25b4
Reviewed-on: https://review.haiku-os.org/c/860
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We don't include the wpa_supplicant on the minimum image, so
these aren't very useful (it seems one needs the wpa_supplicant
to connect even to an unsecured network, with our setup.)
Anyone who needs one of these and also has a reason to use the
minimum image can easily add them back via their UserBuildConfig.
* Remove parenthetical about cross-tools not being needed on Haiku,
as they are indeed on x86_64.
* Replace mkisofs/genisoimage with xorriso.
* Move mtools to the list of tools generally needed, as EFI builds
require them.
* Update clone URLs and GCC version numbers.
It seems that not all Linux distributions ship an EFI-enabled
cdrtools (i.e. mkisofs takes -e option), Arch being one that
does not.
So instead, we now use xorriso universally, which is
as (or more, in most cases) widely available, and supports
emulating mkisofs with the EFI commands universally.
This also has the added benefit that we can drop genisoimage
support altogether.
This method is much less error-prone than the prior one, as that required
the driver structure to have an exported symbol identical to its "name"
field, a fact that is usually true but not always (we've had an ifdef
in the atheroswifi driver for a while now due to this.)
So when we have it, we now just use the driver_t* directly, which
should push any of these problems from the run-time stage to the
compile-time stage. It's also a significant performance
improvement.
* Print a message when not resuming a thread because it is running.
When I was using this command while working on ipro1000, I assumed
that "no news was good news." But it seems that wasn't the case.
Hopefully future developers will be less confused after this.
* Allow resuming threads that are in "asleep" or "waiting" states,
not just in "suspended" state. Presumably a developer poking around
in KDL knows what they are doing, so allowing them to do this
seems to make sense.
... and B_DO_NOT_RESCHEDULE unset. We already have equivalent panics
for mutexes and condition variables, so it seems to make sense to
check for this too.
There have been some bug reports recently about hard deadlocks with
symptoms (i.e. kernel debugger can't even be summoned) that match
"interrupt handler thread was context-switched while holding interrupt
lock," and this is the only major remaining path to that without
such a check.
This would have also helped me with recent FreeBSD driver porting;
I forgot to pass the flag once and deadlocked my system in precisely
this manner.
