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.
Now that we use SYSINIT for the "module" code instead of manually
maintaining lists, we have to make the static library slightly differently.
See inline comment.
Changes to the Haiku module will come in the next commit.
There are a few Haiku-specific changes in here; most notably some
hacks to prevent struct size changes from breaking wpa_supplicant,
and a removal of the full ieee80211_channel structure from some ioctls
where we previously returned it.
FreeBSD 12's net80211 layer contains only 2 small KPI breaks from FreeBSD 11,
so we can upgrade it, apply those 2 changes to the drivers which are affected
(as the changes are in some lesser-used functions), and then upgrade all drivers
one at a time.
* Remove cast to void* in AddItem() at line 775, so that
avoid that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I0722661611d0393896c1aac161a702a4c2f1d5d8
Reviewed-on: https://review.haiku-os.org/c/857
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
* Remove cast to void* in AddItem() at line 363, so that
avoid that the object which was created using 'new' operator
is immediately cast to another type.
* Also remove other casts in AddItem().
Change-Id: Ia20ab39ef50dce12b9d06ca5b1736a8a8e3e9cdd
Reviewed-on: https://review.haiku-os.org/c/856
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
The currently included version of libfreetype already has the LCD
subpixel filter turned on by default. With the switch from my
"averaging filter" back to Adrej Spielmann's filtering, there was now
another filtering being done on top of what Freetype already does.
There also seemed to be a problem with the left edge of cached
glyph bitmaps, which I didn't bother to look into. The visual result
of this change is that text looks much crisper, and the display
bugs at touching glyphs is gone.
On the other hand, LCD sub-pixel rendering is still turned on
globally, i.e. for all vector drawing, and for uncached rotated
text. The Freetype filtering is not applied there. This problem did
not exist in my "average filter", since it happened at the scanline
rendering level, not only for cached glyph bitmaps. It is however
not a regression introduced by this commit. It needs to be fixed
separately.
Change-Id: If93c2b85ed479670e6679227984fd8d9f77c11f6
Reviewed-on: https://review.haiku-os.org/c/855
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Also implemented recording DrawString(string, length,
BPoint[] locations), which was previously not recorded at all.
* Also implemented playing back recently added drawing commands
in PicturePlayer.cpp. I don't quite understand what this is
actually used for, but it seemed it was forgotten. I just followed
the pattern already established in the code.
* The other important bit in this change is to update the pen
location when it is needed while recording a BPicture. Often
the BView will use PenLocation() in order to transmit drawing
commands to the app_server which use absolute coordinates only.
This isn't actually so nice, since it means the client has to
wait for the server to transmit the current pen location. If there
were dedicated link-commands for pen-relative drawing commands,
the client could just keep sending without waiting for the server.
In any case, the app_server needs to update the pen location in
the current DrawState and even the DrawingEngine even while
recording a picture, because some next command may need up-2-date
state information, such as the font state and the pen location.
* I have not yet tried to find /all/ instances where the DrawState
needs to be updated while recording. This change should repair
/all/ font state changes, all versions of drawing a string, and
all versions of StrokeLine().
Change-Id: Ia0f23e7b1cd058f70f76a5849acb2d02e0f0da09
Reviewed-on: https://review.haiku-os.org/c/817
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
This time we use the pci_info directly, it avoids a possible race with
PCI config regs, and we already have the value there anyway.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
One crucial fix by me: check if size == 0. This avoids the deadlock
seen in #14795.
Includes some logic fixes to Haiku-specific code in the MII drivers,
and one new chipset supported by the rtl81xx MII driver. Otherwise,
no major functional change.
