* Fixes problems with setting the partition name after uninitializing
a partition in DriveSetup. Previously, UninitializeJob() was
followed by SetStringJob(), but the kernel was updating the
change counter for the parent partition when uninitializing a
partition, leading to SetStringJob() having an incorrect change
counter for the parent partition. Now the parent change counter
will be correct when SetStringJob() runs.
- According to the Be Book, one of BListItem::Update()'s responsibilities
is updating the item's internal height/width. However, while we were
providing such updates in the case of the item initially being added
to the view, or when the list view's font was changed, we were not doing
so on frame resize. This would lead to items having a stale width field
in such a circumstance, leading to possibly incorrect behavior in apps
relying on that field to be correct.
There are some delays in making the actual package repo generated by the
buildbot go live. Until then, I'm going to manually update the existing
repositories with the built packages, so people can start to experiment
with them and report any new issues.
There are more updates coming, but I'm doing them gradually so we can see
which set of packages triggers a regression, should one happen.
* Ingo rightly noticed that the defer_signals counter is reinitialized on
thread's user area creation. Setting the flag THREAD_CREATION_FLAG_DEFER_SIGNALS
indeed gives the expected behavior, deferring signals until undefer_signals() is
called in the child thread. Thanks for the review and fix suggestion.
* Added a simple test showing the values of the defer_signals counter after fork().
* This fixes booting Haiku when creating a brand new GPT
partition layout with the BIOS/MBR.
* This also fixes boot issues with UEFI based on OVMF, which
rejects GPT partitions that don't have the protective MBR.
* Also defer signals while registering fork hooks.
* While malloc provides fork heap hooks which lock the heaps and unlock/reinit,
malloc_debug provides empty hooks.
* Ideas suggested by Ingo, patch reviewed by him. Thanks a lot!
* Also call fork parent hooks on failure.
* Solve locks-up when combining multithreading and process forking, should help
with #13111.
It doesn't work, however; it throws an error message about failing to connect
to a port, which I presume was caused by the launch_daemon changes. If
Axel could take a look at it, that'd be much appreciated...
* There's no need to supply ways to mismatch the buffer duration
and size. Anything should reflect the media_format, this is at least
fixed on API level.
* There's no point actually in providing BTimeSource dependant
functionality. If and when there will be need for something like
that, possibly never, an higher level solution will be integrated.
If WP is not enabled then the kernel can freely write to read-only user
pages, which breaks copy-on-write.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
This is separate to the VESA driver, as the VESA driver requires
using the VBE BIOS. Under UEFI, we don't have the VBE BIOS, nor
are we able to switch modes after leaving UEFI Boot Services, so
a dumb framebuffer driver seemed like the easier way to approach
the problem.
The framebuffer & vesa drivers now test for the presence of the
VESA_MODES_BOOT_INFO boot item to distinguish between which driver
to use. Also added check for the VESA mode count to determine
whether to add the VESA_MODES_BOOT_INFO item.
UEFI video updated to explicitly zero out the VESA and EDID
boot data.
The SpinLocker was always initialized to fThread->time_lock even though
fThread may be NULL. This looks like a simple oversight as the rest of
the method handles fThread being NULL and the team variants of these
timers have very similar logic and do the NULL check as well.
This fixes the last remaining KDL in the posixtestsuite.
DebugReportGenerator:
- In the case where the function was already disassembled beforehand,
we weren't retrieving the statement, leading to a null pointer
dereference.
According to the FreeBSD kernel malloc man page the allocator is
expected to return power of two aligned addresses for allocations up to
one page size. While it also states that this shouldn't be relied upon,
at least our (directly copied) bus_dmamem_alloc expects it and drivers
may depend on it as well. Looking through the FreeBSD commit logs, this
expectation seems to be rooted quite deeply.
This fixes watchdog timeouts in the ipro1000 driver under KVM and may
help with #11953. It might also be related to #9099 and #9601 as those
seem memory allocation related as well.
