we check the OpRegion version and use the rvda pointer when available.
from 2.1 the pointer is relative.
Change-Id: I64d8aea65368aa3c5597f63a2b96b6a430e04315
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5109
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* solves #17659
* We assigned the volume label to the root, but not the boot
sector (partition boot sector, not MBR)
Change-Id: I9c53204c18709c2d225cc8ea338290aa89d42083
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5106
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Obtain the size of local package files.
Fixes #17445
Change-Id: Ica15d3f7c1e80bcf9b3b23d6af851cc33b5b6253
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5016
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
Yet another 16550 clone under a different name. Why does device-tree
have a "compatible" setting if everyone puts a different name for the
same thing?
Change-Id: Ia889a527a36739df747ba48d4606c09764703607
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5103
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
They were hardcoded to 2, which is not correct on all devices. As a
result, getting addresses and sizes on pure 32bit devices would fail.
Change-Id: Icf542c9e8d6b7136219014fe08dd601387de4762
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5102
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If mprotect() is being run over an entire area, and the area does
not have per-page protections, then we can just invoke set_area_protection
instead of allocating a protections array.
This is a major efficiency increase, as every page fault would otherwise
have to use the protections array if it was allocated.
Testing with QtWebEngine shows this new path being hit relatively often
(multiple hundred times in loading a single webpage).
Change-Id: I60258d56f681060861602922f3fbdbce2fd380d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5097
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* We should not assume all non-kernel areas have KERNEL_READ_AREA
permission, but follow the other permission flags directly.
This way the kernel will be blocked from accessing guard pages, too.
* Compute kernelProtection only once, and either return it directly
or return it OR'd with the user protections.
Change-Id: Id6daa1cd15eb3102e23f95c08672ad97344e0722
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5096
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It already checks for area->page_protections == NULL and returns
area->protection appropriately if so, we do not need to test specifically
for that here.
No functional change intended.
It's entirely possible that we have a user area with a page that
has protections of 0 (e.g. a guard page). In that case we should
print the standard read/write fault message instead of "kernel"
fault messages.
This should not be a major behavioral change, only the syslog
and tracing entries should be affected; such memory accesses
should be caught by the read/write permissions checks immediately
following.
It seems this is the type of the innermost source cache, not the
topmost cache (which well may be "RAM" if this is an anonymous cache
on top of a Vnode cache.)
Originally VMArea::cache_type was introduced 15 years ago
(commit 0c12332715, 2007)
merely to mirror the underlying cache's type. Somewhere along the way,
it acquired different values. As the VM has changed a lot since then,
perhaps its overall purpose should be re-evaluated?
Fixes #17556.
If these methods are called while the interface in question
is receiving data via a receive thread, we can hit a deadlock
where a receive thread is holding the receive lock and then
tries to call get_interface_address_for_link (due, e.g., to ipv4
checking is_local_link_address), which tries to acquire the interfaces
lock, while at the same time we are trying to acquire the receive lock
due to CreateDomainDatalinkIfNeeded invoking a module's datalink_init
which calls register_device_handler, so we deadlock. (Whew!)
As far as I can tell, we do not need to set Busy() here despite unlocking
the interfaces lock, as the Interface acquires its own lock in
CreateDomainDatalinkIfNeeded.
Observed in VMware when the DHCP client spins for a long time,
and the deadlock occurs upon opening Network preferences.
Instead add a second level to the loop and a small temporary array.
Makes the code slightly simpler (and safer, as there is no risk
of races now.)
Also add a missing "firstCPU +" in the current_frequency calculation.
It seems that has been broken since the frequency value was introduced...
In addition to being slightly more efficient, this also allows one
to see precisely how many vnodes are currently "alive" across all
mounts via the "slabs" KDL command.
Part of the point of published variables is to make them "shareable",
and not require external synchronization. Requiring the callers
to ensure unpublishing does not occur is thus unreasonable, as e.g.
a variable could be unpublished immediately after being notified.
That is the case for some usages of these variables in the FreeBSD
compatibility layer, which under heavy usage, can and did trigger
use-after-unpublishes and then KDLs, at least in local testing.
Instead, only unlock the hash after we have locked the variable.
This is already done in some other functions, so it's safe to do
it here, too. This way, the variable won't be unpublished
while Notify() is running.
This resolves a TODO, and allows B_KERNEL_RESOURCE_ADDRESS_SPACE
to be a bit more useful, as fragmentation will now turn in
to a low-resource notification.
We never included obprintf in the build, and the real obstack.h
exists in the "extensions" folder. Unfortunately, it seems the
BeOS R5 libroot had an obstack.h in the public POSIX headers
directory and exported the functions, so we cannot remove it
completely just yet.
Seems none of the applications I tested yesterday actually used poll(),
because it was completely broken by this.
The previous code assigned this variable inside a malloc() call, though,
which wasn't all that obvious either.
Reset the value of IsFirstClick to true whenever a new game is
started. Without this fix the board gets confused if there is
a card flipped when a game is restarted.
I can't reproduce any of the other oddities in the ticket but
this fixes the egregious repro case mentioned.
Fixes #6932
Change-Id: Ie5cedd7fc2ca411db722d3c24f68fe9aa48f7b5f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5038
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some improvements to allow setting 8, 15, 16 and 32bit modes, and detect
the correct mode number after patching the BIOS automatically, instead
of hardcoding it.
Also move the patching code to a separate file.
Fixes #10570.
Change-Id: I920f448b59ad7373cb8595d92ce3fa52324be67e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4629
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This uses atombios headers to find where in the BIOS the video mode
tables is located. Then, we can replace entries in the table (in a RAM
copy of the BIOS, of course) and inject any video mode we need. To make
the table easy to find, the Atombios headers from the radeon_hd are
reused, but no atombios code execution takes place here.
Change-Id: If1981b1574822d4ce1e072dd6437a727192ce7cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4628
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Get the OEM string from the VESA info block (and also get the memory
size from there while we are at it). If the string is empty, use the
BIOS type (identified in other ways) to still report something.
Change-Id: I8cbd75d19f624a43db05e82d1e1b2a536cc418b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4625
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The VESA standard does not define any way for software to set a custom
video mode, which means normally we would be constrained to whichever
modes the video card manufacturer decided to provide. However, since we
run the BIOS in an emulated environment, it is possible (and even quite
easy) to patch it and inject any video mode we want, provided we know
the format to use and where to put the info in.
This approach was used in the NewOS VESA driver, as well as in
915resolution (a tool that predates the availability of native drivers
for Linux for Intel videocards). Later on it was also used in Chameleon
and Clover, bootloaders that are used for hackintoshes (running MacOS on
unsupported hardware).
This commit implements full support for Intel cards only, AMD and NVidia
will be added later (but there is preliminary code to detect them)
Change-Id: I2c528ba18b3863f486da694860a10761efcbfb3f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4624
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
MSI was never implemented in this driver and only used for a log during
initialization. Remove it for now.
This makes it easier to use the driver on non-x86 systems where there is
no MSI.
Change-Id: I39ccbb82b78ea98c0d045ef07ee9bb28c775e292
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4847
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* move common SMP initialization code to x86/arch_smp.cpp
* factor out arch-specific SMP initialization to
arch_smp_32.cpp resp arch_smp_64.cpp
* implement smp_trampoline for x86 32-bit EFI loader
* rename SMP trampoline for x86_64 to long_smp_trampoline
* add new argument virtKernelArgs to arch_smp_boot_other_cpus
as the kernel args are not identity mapped on 32-bit architectures
Change-Id: I30d0bb1fa9bfb08f6784a2af34eb83d6b64afa57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4869
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
In the Terminal settings window, the pop-up help text for
"Tab title:" had two entries for "%% - The character '%'.".
Removed one of the entries.
Fixed the spelling of some constants: kTooTip* vs kToolTip*
Changing the window title and tab title directly will now
show the same tool-tips as the Terminal settings window.
Change-Id: Ic36cc1f8af0305b757105a229203115efee870c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4989
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Máximo Castañeda <antiswen@yahoo.es>
The options "Refuse in/output format changes" were meant to prevent
format changes of connections on the fly, without tearing down and
establishing a new connection.
The mixer does not support such format changes for input.
With this patch input format changes are refused - the former
default setting.
Output format changes are at least mostly implemented, so we are
allowing format changes here.
Both options get removed from the Audio mixer setup panel of the
Media preferences. The code those settings themselves is kept.
Thanks Máximo Castañeda for the investigation, see
https://www.freelists.org/post/haiku-development/Explain-the-Audio-Mixer-Setup-options-of-Media-preferences,26
Change-Id: Idb2d0674a4701014249bc5252a7e4ccedc4f532f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4934
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Use the User Read-only Thread ID Register aka TPIDRURO to store
TLS pointer.
The User Read-only Thread ID Register is read-only in User mode,
and read/write in privileged modes.
see: ARMv7 Architecture Reference Manual,
section B3.12.46 CP15 c13 Software Thread ID registers
Change-Id: I7bff2fd66f41d7bf1a8a247151bcd02b32733c1b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4994
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
init_hardware now takes 2 devices arrays: one for PCI and one for USB
drivers, respectively.
The few drivers that have their own __haiku_handle_fbsd_drivers_list
are also adjusted at the same time.
It is not yet wired in to the rest of the compatibilit layer;
that will happen in the next commits.
The bulk of the implementation is in usb.cpp; most of the
rest of the new files are copied from FreeBSD to varying degrees.
Otherwise we have a race (or worse): in the case where the transfer
has completed or is in the process of completion between CancelQueued
and here, the callback can still be invoked after we returned and
cause corruption.
Discovered while working on USB support in the FreeBSD compatibility
layer: a lock inversion problem meant these timeouts always occurred
but then the callback would be invoked later and corrupt stack.
With this change, such problems will instead cause deadlocks.
That's not an ideal situation to be in, but we should detect
such problems elsewhere and make them into asserts; deadlocks
are assuredly better than random memory corruption.
Previously they would just get "lost" and never signal completion.
(Considering how rare fragmented transfers are, this may not fix
any real problems.)
* Fixes functionality of TRACE statements on 64-bit platforms.
Change-Id: Iaba8f8b2d49ec1acda3fc2d51e24a207c5bcc97a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4992
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* Resolves an issue compiling icu70
* FreeBSD is 262,144
* Linux is 2,097,152
* Haiku was 131,072
This roughly doubles the maximum args length, and makes us
function inline with FreeBSD today. If we're the shortest
straw, we're going to find a lot of things broken (such
as ICU 70.1) Matching FreeBSD means any limitations we see
will also be seen on FreeBSD, making fewer "Haiku issues".
Change-Id: I677c0523a2f27c9e9901fda4180445bcb6da31b2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4991
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Update as per Unicode 14 (and draft 15)
Include the noncharacters. We don't really want the .notdef glyph for
them, except for U+FDD1 which we have reserved internally to force it
from webkit.
Fixes #17593
Change-Id: I5a62bf0e7753adacc81ea19b3351deb58d5c0653
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4984
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
to find the RSDP, also try to find it in the EBDA area.
Fix trace build.
Change-Id: I94c3fbec9ea97b9187bf6b2c634298f6ae5b413c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4981
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These can be used on platforms that only support memory spaces
and have no other general restrictions. riscv is one such for now,
so this finally commits support for RISC-V in the FreeBSD compat layer.
Now copied directly from FreeBSD.
Also change copyright info of the main file, as the remaining parts have
almost entirely been written by me at this point.
It seems FreeBSD does the same (and drivers used to do this individually
but have not for some time.)
May help with quite a number of initialization-failed WiFi/ethernet tickets.
* Use the standard TRACE{|_ALWAYS|_ERROR} setup.
* Put DBG(OUT... code as TRACE.
Makes syslog output from this module significantly less verbose
in default builds.
In the case the team has already been removed from its process group,
this means we are far enough into teardown that we cannot change it.
Simply check for NULL and then return an error if so.
Fixes #17448.
* Mostly just to be consistent with everything else
Change-Id: I468ce0a20fb918ec6e696bbc9e961dbc4386d7ff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4963
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* The private keys are in possession of Haiku, Inc.
Change-Id: I3b5b004e1dce0102f8a65f6d682f7e428845efe8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4936
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
hrev17117 implemented B_OP_COPY with a special treatment for text.
hrev21929 introduced the color cache to speed up that text drawing.
hrev52753 removed the special treatment of text in B_OP_COPY, but left the
color cache and the text flag behind.
Change-Id: Ib506c80a660e829132bce3ec1cb354fcfbab266c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4931
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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>
The body text on the About tabs for the JPEG & JPEG2000 translators are
BTextViews and so the default fg color is B_DOCUMENT_TEXT_COLOR. This
patch forces them to use B_PANEL_TEXT_COLOR to match the rest of the panel.
As a side note, trying to set the fg color in every translator via
SetHighUIColor seems to have no effect and they seem to all default to
using B_PANEL_TEXT_COLOR already (aside from the BTextViews in this
commit).
Fixes #15941
Change-Id: Ia97dcce082d7f1666c61a8d5ecefa3bcd5845b96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4960
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
gcc generates binaries with segments aligned on 0x10000
because this is the max page size defined in bfd
This change allows runtime_loader to load ARM binaries
without complaining for unreasonable amount of space
between segments.
Change-Id: Iec345980ca7ff72786173772a6deb40f5ca0b0ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4974
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Instead of fork()ing, which leaks memory (and runs a second
BApplication inside the Run() of the original one, which was
the source of a TODO), use posix_spawn to start a second process
altogether.
* Move session initialization code to the new user_main(), invoked
from main() if we are starting a user session.
* Send event registration messages to the new session daemon
in _HandleRegisterSessionDaemon, as the child no longer has access
to the old events list from before fork()ing and must receive it.
The last of these fixes a race: previously, if an event was registered
or triggered between when the child (user) launch_daemon was fork()ed off
the parent and when it registered with the root launch_daemon, those
events were "lost" and would never be forwarded to the child.
That happened not altogether infrequently for some people (myself
included) especially in virtual machines for the "initial_volumes_mounted"
event, which was the most common remaining cause of "boot hangs on rocket"
or "boots to blue screen with only mouse cursor" problems.
So, in addition to being cleaner overall and resolving a number of TODOs,
this also fixes #17365.
Change-Id: I1ea28cba8938a38b3c27685d7f3943f596cfe7ec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4968
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* I have to figure out how to do this every major
release, put here to document somewhat.
* The os images are empty files for obvious reasons
* This vagrant box is used by qemu for their automated
testing under Haiku
https://github.com/qemu/qemu/blob/master/tests/vm/haiku.x86_64
Change-Id: I8e02104063284a96e1672051e3d504a78a64cfe3
This reverts commit d493aae3c4.
The default shine and shadow color are pure black and white. They are
not meant to be used directly, but mixed with the background color for
more subtle results.
The previous code using tint_color was also just fine.
Fixes #17577.
Noticed because Pootle showed "Video data between line lu and lu".
Change-Id: I55eeba9d3df88debbf2121a653b8220e643d07bb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4959
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This way, the first unlucky application to request the font list
after paths change (or on first app_server startup) will not stall out
while the font list is rebuilt, at least most of the time.
Should fix #17574.
As far as I can tell, this TODO has been resolved since 3 hours after
it was added in 2005, when the second case of B_ENTRY_REMOVED (i.e.
single-file removal instead of whole-directory removal) was implemented.
_RemoveDirectory does not appear to be fully implemented, though;
but it has its own TODO and does not need this one.
Now that we are merely doing basic comparison tests and do not invoke
get_thread_info or the like, this is cheap enough that we can enable it
even when DEBUG is not enabled, and get assertions in more cases.
"delete object;" is logically the same as "object->ReleaseReference();"
when there is a reference count of 1, and we need to permit that instead
of asserting on it, so the case where a referenceable object is a member
variable of a class works without asserting.
This manifested in packagefs: the Resolvable class has a linked-list with
Dependency objects (which are referenceable) in it. (Further, the stack
checks do not work quite right for kernel stacks.)
Fixes #17575.
* Put all fields in the same order they are in the header.
* Add missing initializers for various fields to NULL or -1;
while these should be initialized by later routines,
for consistency's sake we should also clear them here.
Instead of the malloc_referenced system. Makes for some cleaner code,
and the malloc_referenced system was only used here, so it can now be
dropped altogether.
This code has been broken like this since 2012, so I am skeptical
that it is the cause of the more recently observed #17463.
It is however possible that more recent changes caused things
to get noticeably worse for some reason.
This may, however, resolve some of the other KDLs, e.g. #12847.
The function is largely useless if we cannot lock kernel space,
and the consumers may not expect it to silently "fail." Hence,
we now put the invocation of deferred_free in free_etc directly.
Save ShortcutName() (i.e. filename) instead of the potentially
translated decorator Name(). If the decorator has no ref but
fInitStatus is B_OK and fPath == "Default" return Default
decorator in ShortcutName(). The Default decorator unlike other
decorators has no file on disk associated with it.
We don't need to look for ShortcutName() when iterating through
decorators anymore because we look for "Default" then file names
before we try to find by name.
Fixes #16412
Change-Id: I3109681d11931e7f55b7afaf3a65af2fb9ed5e10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4320
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
STOPPED errors are generated by StopEndpoint commands, which we issue,
so presumably we expect that we will get some STOPPED errors when doing
so, thus printing these is not really necessary.
This checks the reference counts are actually 0 (or 1 and allocated
on the stack). As PARANOID_KERNEL_FREE is enabled at KDEBUG_LEVEL 2,
this will thus be enabled on nightly builds.
* Adjust a comment that now goes with 3 functions and not just 1.
* Remove spinlock switch function, this is useless as it cannot
change interrupt states here, but we require interrupts to
be enabled to wait on a ConditionVariable.
* Remove WaitStatus function from ConditionVariableEntry; unused
and would require locks anyway.
* Implement Publish using Init.
In the case where a weakly declared symbol has no definition,
it should just resolved to be NULL instead of failing to load at all.
GCC 11 builds of libroot.so wind up having one weak symbol
declaration that is unresolved at runtime, to __cxa_pure_virtual,
which seems to be provided by some object in libsupc++.a that ld
does not pull in automatically (and has to be forced at present.)
This change also amends symbol patcher behavior: it is now possible
for the symbol patcher to indicate symbols should be hidden by
changing the passed-in type to 0, instead. (Otherwise, weak symbols
would always get a value of NULL instead of being able to be hidden.)
Fixes #8288.
Previously-reviewed-on: https://review.haiku-os.org/c/haiku/+/4768
Change-Id: I6485c4e515cb53c6b81db971efbc10008fa6bd9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4932
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This file is used only by the u-boot raw bootloader and
it has identical content to platform/u-boot/mmu.h.
Therefore we can use mmu.h in the u-boot loader and remove
this header.
EFI platform has its own arch_mmu.h in
headers/private/kernel/boot/platform/efi
Change-Id: Ie77774fbcf4855f9bc643176c179670f6169b3b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4929
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Now that the interlocking issues are resolved with the previous commit,
using the main TQ_SLEEP mechanism no longer causes deadlocks and
network I/O freezes, so we can drop the custom code and use FreeBSD's
code instead.
as it's possible they use the audio class_sub instead of hd_audio.
* also power up the audio function, this seems required on Jasper Lake.
* tested on Acer Swift 1 SF114-34.
Change-Id: I603018b1b973e7884aa99a58be1c24e568f2d5ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4928
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Self-unblocking is not done anywhere else in the kernel and may not be
such a bright idea, it seems.
This also allows the elimination of some atomics, and resolves a race
that otherwise would have required another wait-loop. Performance
differences seem to be within the realm of noise.
Fixes #17553.
Change-Id: Id719ba51ed3f2a15557c8d53947182a5f8879b7b
* init works better with this. it doesn't work yet, but at least the boot
isn't completely borked.
* also fix the infinite loop in SoftwareReset() to timeout after 100ms.
Change-Id: I76dac8360eaf3575adf7d0b3bf3e2b72daeedb21
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4923
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 74843df324.
Reason for revert: Change was not ready, see comments on #8288.
Change-Id: I82dc23ca5a86fa2906fb6eb19f9f872603618fad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4897
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In the case where a weakly declared symbol has no definition,
it should just resolved to be NULL instead of failing to load at all.
GCC 11 builds of libroot.so wind up having one weak symbol
declaration that is unresolved at runtime, to __cxa_pure_virtual,
which seems to be provided by some object in libsupc++.a that ld
does not pull in. We could probably force it to be, but implementing
proper weak symbol resolution seems to be the more sensible path.
Change-Id: Ifd512b73dc67581e6173b5c78ce73ac68971707a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4768
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Conversion from pointer to phys_addr_t (i.e. uint64) results
in a sign extension on x86.
Therefore we first convert to addr_t and then convert from
addr_t to phys_addr_t.
Change-Id: Id9d9db03d9940a11ea3892841c271e12fad3975a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4872
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* always use non-linear gain sliders (was the default setting)
* remove functions and members connected to linear gain setting
* remove "(like BeOS R5)" from "Attenuate by 3 dB" option
* add "Low/High quality" to resample algorithm option
Fixes part of #17554
Change-Id: I746da3f5bcc8f0cb017c75509565b535d5442f71
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4917
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* kernel + bootloader get differing compiler flags
* Trying to reuse libroot objects makes what objects
are being built with which flags slightly confusing.
Change-Id: Ic8ac7255db99d6825ca022afc3f4fd416c57c12d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4876
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
UEFI specification states that on IA-32 paging may or may not be
enabled during startup. If paging is enabled, PAE might be active.
During jump to kernel and early kernel initialiation we use paging
without PAE.
Therefore the following initialization sequence is introduced:
* disable paging
* disable PAE
* load page directory
* enable paging
Change-Id: Ife9a631b914dd5867f6673713e20e8abfce1ea44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4919
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The stat structure fields are not standardized, so we can't use an
hardcoded field name. The code in all other places was already adjusted
with a macro to handle the access, but hrev55802 introduced a new place
where we need to read the access and modification times. Use the macro
there as well.
Thanks to anuragpd4 for reporting the problem!
* Matches arm and riscv64
Change-Id: I88874df4da16f5019def0c0c79ca41f37a926c12
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4916
Reviewed-by: <karolyd577@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Similar to what riscv64 does
* Solves incorrect newlines
in qemu serial.
Change-Id: Ib1179728529dd4bf51c8361fdb6190bd43ccb851
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4895
Reviewed-by: <karolyd577@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: Ie42c69f3851acae3a8184aa97ab2dd01c9485f46
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4850
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Empty function for now as no arch-specific calls to
fix_address() needed on arm64.
Change-Id: Ifef100c132eac29a2b763e06bf1efd695b284851
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4894
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Use TRACE() for logging
* Use B_PRI format strings
* Reformat local variables and function arguments to use camelCase
* Remove comment related to ConvertPointer
* Fix indentation for switch statements
* Remove variable sFirstPageTable as it's not really used
Change-Id: Iace275e5a3311f13a5018f497c3132e472a20848
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4885
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Page directory and early page tables are allocated using
platform_allocate_region() and they don't need to be identity mapped
since commits 9103470bd and a7c69a4b1.
Change-Id: Ia7fcf1dd2fa34262e013f651139ad252a1ac9113
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4886
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
hrev55756 fixed regressions but also broke thumbnails.
Tell Model to look for an thumbnail icon in the node in
FinishSettingUpType() if eligible.
Create ShouldGenerateThumbnail() convinience method in Utilities.h
Change-Id: I454156374ec539f5bb09a61f24b16ebb6a7a95a1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4887
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way, applications blocked in usb_raw can actually be killed,
instead of "hanging" until the USB device is removed or the
transfer finishes.
Improves a number of USB tickets, but does not really "fix"
any of the underlying problems that lead to this happening.
We have used and had fallback futimens() implementations in libroot_build
(and in this file even) for over a decade, but nobody seems to have noticed
this bit of missing functionality which can be implemented with them.
In fact, this is rather important bit of functionality, as "copyattr"
relies on it to preserve the mtimes of copied files; and we use
recursive copyattr many places in Haiku builds. Thus, the lack of
an implementation here was the cause of all files in built Haiku images
having timestamps of whenever the build was done, and not whenever
the file was actually modified.
This should make development on Haiku nightlies much more pleasant,
as the system headers from the haiku_devel package should no longer
have always-current timestamps with every upgrade.
First try to allocate a page below 2GB.
If it fails, try to allocate a physical page at the address
returned by get_next_virtual_address so that we get an address
that is available in both virtual and physical space.
Finally try to allocate any available page. At this point
it's highly likely that it will be above 0x88000000 so it can be
used for trampoline code.
Change-Id: I3100a3e09efcd938bc630a52dcce74dc5f24beb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4878
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I899f288f451dd4c413403cd0e14a855f68355050
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4866
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
All the regions allocated via platform_allocate_region() are mapped to a
high virtual address so there's no need to do identity mapping for them
any more.
Copy kernel_args to a region allocated via platform_allocate_region() so it
will be mapped similarly.
Identity mapping is still needed for trampoline code for jumping to the kernel
Change-Id: I844a7a789b440a38521db49adc077bb77e658ddf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4865
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
A few invalid ones were introduced in 2071dc2
Change-Id: Icbe5bb4aafd9d6e03ec4175c10eccdb2e65465d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4874
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
EFI runtime service memory areas are remapped to a high virtual address
allocated with get_next_virtual_address() to avoid any address space
collision.
They are also added to virtual_ranges_to_keep so that the kernel knows
that these ranges should be reserved.
Change-Id: I63e1a2450fceff3b2404154907a2cf59dd1b373b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4863
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Remove the dependency on identity mapping for the initial page tables
used in MapEarly / _EarlyQuery.
The initial page tables have to satisfy the following conditions instead:
* the inital page tables shall be allocated in the same region as the initial page directory
* this region shall be mapped contiguously
* the page tables shall be mapped at a higher address than the page directory
Change-Id: I34854ef93826aa48f5d90582b52905e553f3d275
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4857
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
UART is mapped to kernel virtual address range since commit f5f10a9ec
so it does not overlap with user address range any more.
Change-Id: If8e18904fcddcbef1ccdc91e526d0e581f61e085
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4856
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
vendor_id shall come after the bitfields
Move hpet_address to separate struct definition so we can apply
the correct packed flags.
see also: https://wiki.osdev.org/HPET
Change-Id: Iced005846fedd4b895910e9b61137d5349db5b41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4859
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* We decided to not create our own custom define checks
and go with the standard ones for riscv64.
* clang doesn't define __RISCV64__ either, so this moves
the clang build of riscv64 a bit further
Change-Id: I2a6c3751168a898c1617b32f46055a9ba1609e2b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4861
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This make it look much better on haiku with dark theme.
Looks the same on default because shine is set to white/very bright.
Change-Id: Iecab3477e1fd5a90c447bcc15a1c598450b074a9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4706
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* The "size" parameter is the size of "out" not "in", and the
return size_t parameter is supposed to always have the total amount
of wchar_ts needed, not how many are actually used.
* In the case where "outSize == 0", we set "requiredSize" and then
return.
Fixes crashes seen in glib2 Unicode collation routines, which
are used in GTK file dialogs.
Thanks to PulkoMandy for glancing at this.
The scrollbar on some areas is misaligned
with the window frame. This change will fix
this. The class that implements the scroll-
view is also shaded by two class definitions.
This is also fixed by breaking the definition
into its own file.
Fixes #16169
Change-Id: I71372906e165672c9b697ab98181ecfb1b09fb43
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4849
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The old versions used pixel-count dimensions, not pixel-span dimensions
as the entire rest of the API does, which was probably a mistake
in the first place. The new APIs using BSize always use pixel-span
dimensions.
The old versions will shortly be deprecated.
Discovered while working on Xlibe.
Change-Id: I604a5ac6e0588420ff0b667d9193d60ac27b92c6
The USB < 3.0 init code has this, and the XHCI spec indicates that
software is responsible for dealing with this still, indeed.
Noticed by rudolfc when testing some USB audio devices in #1045.
The current style probably has the correct style flags portion. Getting
a new style in that case is unnecessary, and problematic with some font
families that have several fonts mapping to the same style flag
(SemiBold, Bold and ExtraBold are all B_BOLD_FACE, for example): the
chosen one might be different than the one already set.
Fixes #17229
Change-Id: Ie8e73627cc0547df9d624a8fac07f521fc983d06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4416
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
-detect if model > HD600
-apply change by calling ATOM_TRANSMITTER_ACTION_BL_BRIGHTNESS_CONTROL and ATOM_TRANSMITTER_ACTION_LCD_BLON
Author : Anarchos <sylvain_kerjean@hotmail.com>
Change-Id: I30b9dd66c71e05427b827fc3ef2c7fa6c498646f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2786
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
By updating $fdt_addr_r we can simplify boot-arm.scr.txt.
Now we can explicitly pass the device tree address to bootefi instead of
relying on a fallback inside U-Boot.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Change-Id: Ifceb574aca2814605a2e4e58e9187773817c5df2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2970
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: Iff9e4198aca706097889faf51e9559fe551126ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4782
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
check that the correct BIOS is found with the device and PCI ids.
make the allocated rom area bigger like Linux, otherwise page faults occur.
Change-Id: Iae6ff1c8dfd81ea16c20e73d511f9a0a96f9b071
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4844
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Regression caused by refactorings in hrev55348.
The logic for deciding when to use a built-in tracker icon was changed
incorrectly to ignore attributes on directories, trash, etc (anything
but executable applications). So the built-in icon was always used.
This commit restores the previous logic.
Shoud fix #17320 and #17371
Change-Id: I51ba22db59a8b6dd2bd1121b56c753ed47224c57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4841
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* This was originally added in hrev55661 for x86_64
* riscv64 suffers the same issue after updating to gcc 11
* Presumably, all architectures might suffer from this,
so apply to all remaining architectures
Change-Id: I41f2adeb5153ce4f4094d667ae303394d537d8ec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4837
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Moved machine mode code from kernel.
* Added MMU page table generation.
* Added QEMU ramfb video driver.
Change-Id: Icd67cd2e8dbf2b568d81ab8dd0d6127ca3cd97a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This partially reverts commit cc0226fad0.
This commit caused high CPU usage in app_server. The double buffering in
ActivityMonitor is not to avoid flickering, it allows to draw just a few
pixels of the the curves at each update, and reuse most of the bitmap
from the previous run.
Removing this means all the curves are fully redrawn at each update,
resulting in higher CPU usage (one core at 30% on my machine with 5
different graphs).
Keep the part of the changes removing code for custom background
drawing. B_TRANSPARENT_VIEW flag can be used instead.
Change-Id: Ie3438ca634c934f3e96ce5f7ad71ce7b3a435013
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4833
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Skip pixels with a coverage of 0. Since the source alpha channel is
ignored, we would otherwise cover pixels that shouldn't be.
Fixes #17449.
Change-Id: I373672a765b99efce5dceed4ffa81741f78b9d9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4836
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The info is now available in cpu_info, we should do something with it.
Change-Id: Iac7bd697783d63b5c84c7da33770b3c9a7d417b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4832
Reviewed-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
arch_elf is reused between the kernel and boot loader
No change for kernel mode compilation.
How to select 32-bit or 64-bit when building boot loader:
* build both when building BIOS loader
* build only 32-bit when building 32-bit EFI loader
* build only 64-bit when building 64-bit EFI loader
Change-Id: I9caa1248c7eb24318911a0c369137cedb638e4e4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4817
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Build both when building BIOS loader.
Build only 32-bit ELF support for 32-bit EFI loader.
Build only 64-bit ELF support for 64-bit EFI loader.
Change-Id: I88bb287fbb9a4b6618b365b2d03f85f64021f499
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4818
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This code was written with wired ethernet in mind, where changes are
rare. However, on wifi the "media" changes all the time (switching
between different connection speeds). So, only log linkup and linkdown.
The other events are not that important.
Change-Id: Iaafb74ceb05a59dedf94184eee23a4e81fa5e983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4827
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Number of retries could overflow. If we retry something more than 255
times and it fails, just stop, instead of flooding the network with
bogus requests
- The timeout could also overflow. It was stored in microseconds in a
time_t, which allows a bit more than an hour. This is fine for the
initial timeout (which starts at a few seconds and will go up to 64
seconds), but after that we switch to a slower rate driven by the
"state time". In particular, this can be the lease time, which DHCP
servers may set to several days, or at least easily more than an hour.
- The computaiton of the timeout in the "slow lease" case attempted to
do "not less than a minute", but missed a conversion from microseconds
to seconds so it ended up doing "not less than 60 microseconds"
The combination of all these things means we can end up with a negative
timeout, and we will send a burst of requests without ever stopping,
flooding the network.
Change-Id: I0eb811c90f4a4dd8c9d92bff728bc2bbb52fbd56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4826
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
used by PR_OpenSemaphore in NSPR to check the creator inited.
Change-Id: I626c6ab0d50896c94224718ca4fa0788f74ae27a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4824
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* We pack the first 8 bits into a union for the raw
edid since alignment matters.
* Handing the raw_edid is a bit ugly, so in the edid struct
we drop the input_type from the union since packing doesn't
matter as much.
Change-Id: I32dbfe9484f9eb83cf491a44d30a32ca36d65b7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4775
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
each poll_fd struct should be checked, valid when not -1 and revents not zero.
Change-Id: Ia624ad1369ad1a6066c9970a47cfac63fa773702
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4821
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
the socket interface module checks the receive.low_water_mark to automatically
notify a read event. available_data will be zero, thus enabling the notification.
fixes the test poll_nm in NSPR.
Change-Id: I5354faec439df96671506550cdb144a45f6082b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
PulkoMandy in cb3199681e changed
the _GetDomainSupport functions to always Ref() the the object.
However, that means in the case of the second _GetDomainSupport
function, which is implemented in terms of the first, we should
not call Ref() as this will create a double-reference.
Fixes a memory leak.
Change-Id: Ib82b2dadc0c8cc8d8f95efcffeb2430ac602a0a9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4791
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
LGTM seems to provide GCC 9.2, for which the flag -Wformat-diag is falsely
detected as supported.
Change-Id: I95a5946d9c6cd2af73e85070973f855fba3fcc39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4786
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
LGTM build failed since -Wformat-diag check is failed.
So we add g++ to check its version in LGTM.
May help to fix #17460.
Change-Id: I9400dbbab7800c522bf7ed797adae48299581a4e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4780
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Using a memcpy here is supremely dangerous, because we are writing to
an app_server buffer that we chose the length for, but using a size
that came from the client. And, indeed, because the buffer can contain
padding if the BBitmap was allocated with a non-standard BytesPerRow,
we will overflow the buffer and corrupt memory, causing app_server to crash.
So, instead, reorganize parameters a bit, and pass BytesPerRow along
with the other data needed to instantiate the bitmap, and then use
ImportBits.
Fixes an app_server crash I triggered with the experimental libX11
compatibility layer.
* Cut extra calls to display_get_encoder_mode
* Correct incorrect ucMiscInfo on table 1.6 via atombios
comments
Change-Id: Ib6d7938269b8421d3711c1344eab0b9842336932
* Looks like some error in atombios. AMD just
reversed the values instead of fixing the atom.h
defines in Linux.
Change-Id: I440682af5708ce0da1625e8f50e8cb77595c8397
* A first attempt at improving on #17377
* We haven't actually seen any cards using this
routing stuff yet pre-navi.
* We don't use the router information yet... but this might
improve things a bit on new cards.
Change-Id: I17962dfd8bb09e619a6084cd9571ccb9832fb19a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4697
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: If7feffafea4fc6d295d04f696127c8f0fbd8fb9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4704
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The previous round of this code unblocked after unset universally,
but that was incorrect in the case where the thread was not in
the "waiting" state before we unset. Yesterday I changed that to
just unblock before unset universally.
It seems, however, that thread_unblock is so time-consuming
that the other thread will wake up and begin doing things
before unblock returns for us, and then it will hit the timeout
before we have a chance to unset. So, now we unblock later
if it is possible to do so.
It seems very strange, though, that thread_unblock will
not return in a small but significant number of cases
before the unblocked thread actually starts running (note
that we are in interrupts-disabled mode here, so that is
not the problem.) That sounds like a problem for another day.
Should fix #17455, possibly in tandem with the previous commit.
This also fixes a leak of slots when initializing devices failed.
Fixes #16323, although there is some other underlying problem
which led to that error in the first place.
It is defined as a uint32:1, which apparently becomes an "int" on
newer GCC versions, which thus triggers a -Werror=format. So,
convert it explicitly in order to prevent the error.
In GCC 8 builds it is by default, in GCC 11 builds it is weakly
defined, which runtime_loader does not yet support properly,
so we force it to be included.
Unblocking after unsetting fVariable just causes too many headaches
and corner cases to deal with; the code as-is did not actually handle
all of them, as it missed the case where the entry thread had called
thread_prepare_to_block but had not yet actually blocked.
Hopefully the last fix for #17444.
* Removed i2c keyboard handler, as it was just a hid shared handler duplicate with kdl stuff removed
* I've created a new macro def for the kdl code, splitting generic kdl code from specific usb one
* I2C custom KDL code can be added in the future (I don't know if it is already possible)
I am not very happy with this solution, but imho it is better than having two keyboard handlers. In fact, they were already out of sync from last patch series
Change-Id: I36513e57a2ce4f004fc7e05ccff5a6b2517fc139
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4758
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If a thread executes a system call and meanwhile a different thread calls another one, then
the ongoing call is marked as unfinished. When the call returns it will be marked as resumed.
* remove PreSyscall, now unused.
Change-Id: Iea45b866be2c40568d766c2ed3cc73e34b9d1293
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4765
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
in the case of poll(), the events should be printed before the actual syscall,
and the revents after, while taking in account the return value.
thus B_DEBUGGER_MESSAGE_PRE_SYSCALL needs to be enabled and handled.
the attribute "preSyscall" is added to identify such syscalls, and the parameters
are identified with the attribute "inOut".
Change-Id: I390643ea176c720738c5ec4fc75a3a4c7125a3cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4763
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
For now this is used on RISCV64 to indicate that interrupts will always
be on CPU 0. However, in the future, some architectures may want
or require interrupts to be "steered" in various ways, and this
also paves the way for that.
Change-Id: Iec79870cf5c4898d102d0e624de19602271ae772
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4721
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Factor out the code for clock frequency lookup to a separate function.
PL011 does not have clock-frequency property, it has a clocks property
instead, containing a phandle of the apb clock.
Change-Id: I5cbe2b4b2421afe1924c2804002ceef83ce37ef9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4734
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Don't match PL011 for arm,primecell compatibility string
as it can indicate other peripherals.
Primecell peripherals have the generic "arm,primcecell"
name as well as a specific name in the format of "arm,pl???"
see:
https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/primecell.txt
Change-Id: Ida6450e9e71dac834770d558e4ab95c5574970cb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4733
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The dirent struct is not packed, so offsetof(dirent, d_name) != sizeof(dirent).
Thus in order not to waste the alignment bytes (which are significant,
on x86_64 at least, sizeof(dirent)==32, but offsetof(...)=26.)
This is also the most portable way to handle things, and should
work just fine in cross-platform code that has a non-zero-sized d_name.
Otherwise if the file cache calls us again from a different thread,
as it sometimes does when doing concurrent I/O to multiple files,
we will deadlock.
Fixes #14104.
This driver was fully C until relatively recently, when it was
switched to C++ so that it could be used with fs_shell. However,
it still is mostly using C paradigms; so this commit begins the
refactor away from that.
If I did this correctly, there should not be any functional change.
Change-Id: Id87d17b2e019ccdd1c7f07156cfe2a2124496675
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4725
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
this avoids searching in edid information in this case.
Change-Id: I330341f089f71cd5de657a6630b5414d02db771f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4749
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Before 2019, the entire ConditionVariable system was "giant"-locked:
that is, there was a single global lock that all ConditionVariable
and ConditionVariableEntry operations had to pass through. This of
course was not very performant on multicore systems and when
ConditionVariables see significant use, so I reworked it then to have
more granular locking.
Those patches took a number of attempts to get right, as having two
objects in separate threads that can each access the other not turn
into a deadlock or use-after-free is not easy to say the least,
and the ultimate solution I came up with erased most of the performance
gains I initially saw on the first (partially broken) patchsets.
So I have wanted to revisit this and see if there was a better way
even since then. Recently there have been a few reports of
ConditionVariable-related panics (apparently double unlocks),
notably #16894, and so that was reason enough to actually revisit
this code and see if a better solution could be found.
Well, I think I have come up with one: after this commit, Entries
no longer have their own lock, and instead accesses to Entry members
are almost always atomic; and there is now a case where we spin inside
Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable.
This leads to somewhat simpler code (no more lock/unlock dance in Notify),
though it is significantly more difficult to understand the nuances of it,
so I have left a sizable number of comments explaining the intricacies
of the new logic.
Note: I initially tried 1000 for "tries", but on a few instances I did see
the panic hit, strangely. I don't think the code that is waited on can
be reasonably reduced any further, so I have just increased the limit to
10000 (which is still well below what spinlocks use.) Hopefully this suffices.
Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores:
before:
real 0m23.627s
user 0m25.152s
sys 0m7.319s
after:
real 0m23.962s
user 0m25.229s
sys 0m7.330s
Though I occasionally I saw sys times as low as 7.171s, so this seems
to be at least not a regression if not a definitive improvement.
Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Check RX buffer status when GetChar is called in no-wait mode.
This fixes an 'infinite keypress' issue that used to occur
after 16 keypresses.
Change-Id: I47762de387b07c4fed46cc192cd3b81fdabfb270
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4732
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
GCC still assumes that the dirent has no data past the end for some
scenarios here and still mis-optimizes things. Therefore, drop the
usages of unions altogether, and instead use a casted character array.
Additionally, use B_FILE_NAME_LENGTH for the array, not B_PATH_NAME_LENGTH,
and make sure to add 1 for the NULL terminator.
The lock entry is the first thing in the struct, so this is a no-op
change, but it is safer to do in case of changes, of course.
Spinlocks have been structures for quite a long time, so this was
probably just missed in the conversion.
* Move IsDownloadComplete call into DownloadFileRequest; this way
we will always revalidate checksums even if the file is fully
downloaded instead of skipping that.
* Treat ERANGE as a "bad data" error in PackageManager (it usually means
we have a size mismatch between the local and the server's file)
* If we fail checksum validation or get ERANGE, and we reused a download,
immediately try again without reusing the download. This fixes most
problems that previously required you to delete old transaction
directories.
Change-Id: Ia3079655691b871e0b206e366b59fca0f832c63d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4730
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way, we will get a more coherent crash instead of
an unceremonious one. Follow-up to #17389.
Change-Id: Iffbf421ce85d638628243d5785ba61ff6b9a8043
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4729
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
we don't sample if the last sample is too recent and use the cached result.
Change-Id: I17ed29bda7fe7276f1a4148b3e1985c9d32ae032
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4101
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This file should ideally contain only those things needed
across all system headers, even POSIX ones, and all other
declarations (B_* ones especially) should go in SupportDefs.h.
However, as nothing but riscv64 uses this right now, I've just
moved it to there.
GCC 11 treats [1] as a fixed-length array and not a flexible-length
array, and so some things that used direct strcmp("..", ent->d_name),
for instance, would be optimized out as being always unequal,
which was the cause of #17389. Using a real FLA informs GCC that
there is going to be more than one byte of data, and thus this
fixes that bug.
BeOS used [1] and not [0], possibly because it had to deal with
compilers (MetroWerks? Early GCC2?) that did not support FLAs.
GCC 2.95 does, using [0], and GCC 4 does, using [], so we can go
with that here.
(I did try using [0] for both, which seems to be OK with GCC 11,
but GCC 8 throws errors when d_name is dereferenced directly
as being-out-of-bounds. So, we have to use the #if here and give
newer GCC the [] syntax and not [0] to avoid that problem.)
The real question probably is whether or not we should backport
some variant of these changes to R1/beta3, as software at HaikuPorts
very well may run in to the same issue. (The alternative workaround
is to compile with -O1 and not -O2 for any affected software.) But
maybe this is an argument for keeping with the beta4 schedule of
this coming January...
At present, it does, but that is an oddity we have preserved from BeOS
that the next commit is going to remove. (This commit thus wastes 1 byte
without the following one.)
Most changes are pretty straightforward: only a +1 is needed,
and a few removed from sizing calculations. Some filesystems like UDF
originally passed back the length with the \0 included, so they have
been adjusted further. UFS2 had some other sizing problems which are also
corrected in this commit.
Our dirent structure is "slim": it has a flexible-length array at the
end which must be allocated to whatever size the consumer wants. However,
we use [1] there and not [0] or [], which meant GCC thought it was not
a flexible-length array, and so it optimized various string accesses
that it assumed must be always false. Among these was BDirectory's
check for "." and "..", and so that resulted in infinite loops.
When changing our dirent structure to a proper FLA instead of [1],
GCC then throws errors on LongDirEntry as it has data "after" the
FLA; which is what we want, but there is no way to tell GCC that.
So now we use a union instead, which is the proper way to statically
allocate a FLA.
This is part of #17389, but the real fix requires changing our dirent
structure, which is coming in a separate commit.
As suggested by PulkoMandy. This was done before my commits yesterday,
but those just reverted patches that had only been in since May,
so it's not clear how much this is actually needed. Nonetheless
it seems like the more correct thing to do.
While FreeBSD and glibc feature-guard it, they also feature-guard
a lot of other things that we don't, and musl does not guard it,
so it seems more than safe enough to leave it unguarded.
Fixes compilation errors with GCC 11. (The other possible solution
was including features.h in more places, but this seems simpler.)
The use of the "register" keyword is harmless, though we should eventually
remove it.
Taking addresses of packed members is "mostly harmless" on x86 where
unaligned accesses are OK. It's less harmless on other architectures,
but we sometimes use packed structures when manually aligning things.
Unfortunately GCC throws this warning even when the actual pointer would
be aligned, not merely when it's unaligned, making the warning far too
noisy and not really that useful.
"Found" by GCC 11.
It seems lowntfs and libntfs-3g kind of assume there is something in here.
This may result in broken links, but that's better than crashing.
Should fix #17400.
It is now at https://review.haiku-os.org/admin/repos/jamfile-engine
This was added in the Haiku repository in the intent of adding it to
release images, a long time ago. Now with the packaging system in place,
there is no reason to host it in the main repo anymore (and it was never
actually packaged anyway).
I also added a recipe at haikuports for it.
Fixes #5360.
Change-Id: I4f2a1529cbadf7af8a16025c30a1332108475807
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4720
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Intel recommends first checking for the existence of CPUID leaf 1FH before using leaf 0BH.
Change-Id: Iba677186521e086fa06bcc4fe42eaed4ba030e6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4719
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I found this at the bottom of my TODO list…
- UdpDomainSupport methods were referring to the object through a static
variable when they could just use the "this" object instead.
- Use BAutoDeleter to simplify the code a little
- Style problem (missing != NULL in pointer check)
- Move referencing of domainSupport in _GetDomainSupport instead of
OpenEndpoint. This way the two _GetDomainSupport methods both return
an already referenced object
Thanks to Axel for the code review and sorry for the super late reply.
Change-Id: Ic50ebb1a63a203d5aa393d28f4631c345acacc79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3908
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Due to how API versions work, it seems this flag is still applied
on a lot of applications, as some have some rather old API versions
(actually API versions themselves may not be working quite right, to boot.)
All relevant software should have had a chance to be recompiled on
or after beta2, so we reduce the flag's automatic application back
just to BeOS applications.
* Add some things to config.h for C++ friendliness.
* Import some more GPL code from libntfs into lowntfs.c,
in order to avoid reimplementing it (or copying & pasting,
which would probably make all the glue code GPL.)
* Write an entirely new kernel_interface.cpp, modeled after exfat's
and other newer filesystem drivers. Highlights:
- significant use of C++ RAII objects
- entry_cache support
- file_cache support (thus also read_pages)
- readdir of multiple dirents at once
Most NTFS tickets open at present are related to write support,
and this does not yet have that. It should however be considered
a part of #17165.
Change-Id: I6d5aa53d4d06846b0de5e6ce1431219bf70a6f2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4679
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It originated on BeOS, and still retains a number of relics of that.
It did not support the file cache, it was rather slow on large disks,
and it had incorrect unlink behavior (delete immediately rather than
on vnode close.) It also is C, not C++.
libntfs-3g has also undergone significant changes in the time since
this driver was written, and it also has a "low level" FUSE module
that we can reuse a lot more code from, so a new driver will be
able to shed a lot of code and use more from upstream directly.
That is coming in the next commits.
Change-Id: Id6f8f8f85076dda92b289ef5a2f1ca6cd484f3e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4678
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Things seem to still work OK ... insofar as they ever did.
Change-Id: I32ba3c71c27106558092fee636f135f477f1cf36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4677
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Normally we are only reading or writing from one field in the stat,
and so we do not need to worry about initializing the others. However,
in the case of timestamps, we use only the "tv_sec" field, and so
the "tv_nsec" field was getting passed to filesystem drivers with
bogus data (on x86_64 at least, very large values.)
This went largely unnoticed, despite being used in every Tracker copy
operation, because BFS only uses the lower bits of tv_nsec.
But NTFS and others use the whole field, leading to timestamps
far in the future.
This may fix some of the issues on the bugtracker about timestamp
problems in filesystems other than BFS (and slight inaccuracies in
BFS timestamps on copies, too.)
Change-Id: I5fdbd264fb145af57b7bf2f7b491c6943024811e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4707
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* A few things need alignment, instead of forcing them all
to align themselves, support alignment of the kernel_args
* Default of 1 is "no alignment"
Change-Id: Iff05dcec8adaa963c8444d701464ea11616062f6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4698
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Catch errors and report them in bus parsing code
* Align the FDT kernel_arg to 8-bytes
* we still choose BSD-2-clause :-)
Change-Id: If2a88b7f131025ff1c1a2d903ed52f039e5bbcb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4694
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
this allows apps like vim to select a color scheme based on a dark or light background.
Change-Id: Ia9f98d2373523a8b5fa379225a1c906ae075edf7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4693
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I49579b206ba4d6a83e0e3a557fc5d4bad6a1a886
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4695
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is one more change to prepare for the transition to soft-float for the ARM EFI bootloader.
We need this change to remove the kernel compiler flags from .S files for the bootloader. Otherwise there would be hard-float and soft-float flags at the same time, giving a compile error.
Change-Id: I0b66c3c16937228eb76351e359160187d3ab826b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4690
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Found by Scottmc.
Change-Id: Idd10040d798533a0aa731132f7282e7ce1423ed6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4687
Reviewed-by: humdinger <humdingerb@gmail.com>
* These are reproductions of the original 2012 R1/Beta4 design
* The light variant works better on my consumer cd printer.
* The dark variant looks better, but is better suited for
professional cd pressing services.
* I'm releasing these as MIT to be clear
Change-Id: Ibd5248fc7248de6697dd65e8ccae1ba1ae623702
* Move assets to new boot directory
* -hfsplus not valid anymore on cdrtools 3.02
* Throw down some forth I saw in an *old* fedora 12
chrp script. If we ever target ppc64 it might be
handy someday. The text output also lets you know
the cd booted successfully.
Change-Id: I169d887fe8373de1719b98305d01b714f6f6bcbe
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4681
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* Stubs for now with todo's matching sparc port
Change-Id: Ie1c0ea523e26fd16066acb26dd83735b89800f31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4680
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
@ -5,7 +5,7 @@ Open Terminal Team monitor Uçbirim'i aç
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural, other{Yeniden başlatmak için CTRL+ALT+DEL'i # saniye basılı tutun.}}
Restart the desktop Team monitor Masaüstü'nü yeniden başlat
Force reboot Team monitor Yeniden başlatmaya zorla
Team monitor Team monitor Takım monitörü
Team monitor Team monitor Takım Monitörü
Kill application Team monitor Uygulamayı sonlandır
Cancel Team monitor İptal
(This team is a system component) Team monitor (Bu takım bir sistem parçasıdır)