Bootloader:
* set permissions to kernel read/write, no user access
for initially mapped memory areas
* set permissions to kernel read/write, no execute,
no user access for UART
Kernel:
* physical memory mapper uses kernel read/write mapping
with no-execute bit enabled
* all other pages are mapped as read/write/execute for
kernel and user
* proper access permissions and memory types to be
implemented later
Enforce memory access permissions by setting DACR to
client mode for domain #0, no access for other domains.
see ARM Architecture Reference Manual, section B3.7 Memory access control
and in particular the following subsections:
B3.7.1 Access permissions
B3.7.2 Execute-never restrictions on instruction fetching
B3.7.3 Domains, Short-descriptor format only
Change-Id: I8127b4c72dc516d013cb9751d80d6f3a9ec835e6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5233
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
These particular responses will not have a body. This is now handled by the
BHttpSession object. There is also a minor fix in here that prevents a crash
when multiple requests are handled by the DataThread at the same time, and not
all of the requests have events.
Change-Id: I7f47d8b3cd8491c8193275be4b3fc1080780fa20
This initial implementation contains a lot of extra debuggin output that will
be removed in future changes. It is now possible to run a simple GET request
to the test server with gzip encoding.
Change-Id: I2c402e5cf80b94b366563888222a891a1b094b7a
This change also drops the principle that fields with the same keys would be
grouped together. This was initially inspired by Boost::Beast, but it means a
lot of extra copying of data when adding/organizing the list, as well as
inefficient querying on each add. Now that the design choice is to fully go
for the raw string as underlying data storage, that choice is not necessary.
In the future it may be able to emulate the grouping or retrieving of lists
of values in the API, rather than as a fundamental principle of the data
storage.
Change-Id: I2667cfa38eb3b7b75393ee71fb038231a40b4193
This assumes a Gen9 or Gen11 configuration, and aux channel 0. As a result, the same EDID will
be found for every DDI port. The mapping should be found in the VBT.
Tested on KabyLake and JasperLake
Change-Id: I27f5ac8ec8e6ba519fbe9aaf745e78a7361175b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5175
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Newer devices use a different layout for the backlight PWM registers
- Get the min brightness level from the BDB
Change-Id: I99745a022dd38733a4c2386f91c4c57016dd2acd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5162
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The old implementation used the real lock_memory(). This is problematic
and does not work for a large number of reasons:
1) Various parts of the kernel assume memory is locked only very
temporarily, and will often wait on locked memory to become unlocked.
The transient nature of locks is further demonstrated by the fact that
lock_memory acquires references to structures, like the address space,
which are only released by unlock_memory
2) The VM has a hard assumption that all lock_memory calls will be
exactly balanced, and maintains internal "WiredRange" structures
on areas, etc. corresponding to the original lock_memory calls.
Maintaining separate data structures as this code did is a recipe
for even more problems when the structures are manipulated separately,
leading to confusing or incorrect behavior on unlocks.
3) Areas with locked memory cannot be deleted, nor can the pages which are
locked be removed from the areas/caches. This of course is most notable
when destroying teams which locked memory, but the problem also occurs
when just using delete_area, resize_area, mmap/munmap, etc.
Because of (2) and especially (3), adding support for mlock()-like semantics
to the existing memory locking system is just not a good option. A further
reason is that our lock_memory is much stricter than mlock(), which only
demands the pages in question must remain resident in RAM and cannot be
swapped out (or, it seems, otherwise written back to disk.)
Thus, this commit completely removes the old implementation (which
was seriously broken and did not actually automatically unlock memory
on team exit or area destruction at all, etc.) and instead adds a new
feature to VMAnonymousCache to block certain pages from being written out.
The syscall then just invokes this to do its work.
Fixes #17674. Related to #13651.
Change-Id: Id2745c51796bcf9a74ba5325fe686a95623cd521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5147
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Resize(): adds more space to the end of the bitmap.
* Shift(): moves all bits in the map up or down.
* Use size_t instead of int for indexes.
Also add unit tests for the new functions (they seem to be passing.)
Reference material for shift implementation:
2c56d43c1e/bitops.h (L977)
Change-Id: Ia85768aaeed7bd3ffef3a9f575f05331e048fe50
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5146
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Internal display on my laptop isn't detected yet so modesetting doesn't
work, but at least I get vblank interrupts and backlight control.
Fixes #17569
Change-Id: I86dd56bc3fc2c288688242e34d9220028036ab74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5156
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
see Devicetree Specification,
section 2.3.5 #address-cells and #size-cells
The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed.
The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
Change-Id: Iafed49358540f8ac7aa673c3dc0191c9b580250b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
BHttpSession::Execute() moves the request into the session, and returns a future BHttpResponse
object. Currently implemented are resolving the hostname, and opening the connection.
There is some scaffolding for the actual data transfer.
Change-Id: I5a8a7a7f8680036b91cdba4beee140bbed6bfd5a
This reverts commit 8497a2cc289f6d991147995507e4efc0ae189147.
The VFS layer is not at all ready for this. Many places in the
code implicitly assume ino_t values will never change. This
functionality is only necessary for live shrinking of partitions,
which is a feature niche enough we do not need to worry about
implementing it in the first round of resizing (if ever.)
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 is a generic error type that can be used by multiple protocols to describe errors that can
occur while processing a request. The error type supports adding an additional error code in cases
where there is an underlying system error.
The type will be used to describe errors that occur while processing requests by BHttpSession, and
it is generally going to be thrown by the receiving BHttpResult.
Change-Id: I76c0bbaedd38df8cfb79159c4beae2fbf1350aab
Incomplete class, but will provide the basis to start working on the internals of the BHttpSession.
Change-Id: I3ca14b7bd823fc1b4a5a32f5784592d214c4e9a7
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>
* 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>
Objects of this class describe a HTTP request. It contains several convenience
functions that will allow a user to describe the properties of the request.
More options to be added later.
Change-Id: If6a00d26808c5ed4b121cb36dc75a2a1cc449f95
* 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>
This class provides defaults and performs basic validation for HTTP Methods as
defined by the standard. They will be used in conjunction with a future
BHttpRequest class.
Change-Id: If69a7ec186d9d1165e8efe5ab5df50d5a089208d
HTTP messages (requests and responses) have a header section that can contain
HTTP headers. These headers consist of name, value pairs. This class can be
used to query the headers on a response, and build a list of headers for a
request.
The internal implementation is designed around two different methods of storing
the underlying data. For HTTP requests, the name, value pairs are stored as
owned BString objects. For responses, the assumption is that there is a byte
buffer that contains the data and that has the same lifetime as the BHttpFields
object. The name, value pairs will then be stored as std::string_view to the
underlying buffer.
Still to do is:
- The method to convert a BHttpFields list into a string buffer to transmit.
- The method to parse a string buffer and turn it into a BHttpFields object.
Change-Id: I4819db100aa1671aa7403675216a4c85fd221da7
