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>
Now only image relative relocations are produced. runtime_loader do not use symbol
resolution for itself and programs can't link with it. Also it is loaded in
special way and do not register in image list available for symbol resolution.
So there are no meaning in self importing.
Change-Id: Iff3cb0ee5ef1dd307134d52c3c911759c59a9b5c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5153
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Some APIs will require the repository source
code to be sent in the future instead of the
repository code. This change prepares for
this.
Change-Id: Iccf0baca077ab81356ed81c18d14122a5b0dacec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5137
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@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>
The revision 1 structure should have 21 items, but on my laptop, it doesn't.
That's fine, we can parse it as if it was a revision 0 structure. This way I
can see the battery status on my machine.
Change-Id: I743173e05318d686049454983e378a08c0a1980a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I1f42447e537ea7522ac299f028d530beb5067350
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5142
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.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>
That's right kids, std::remove doesn't (and can't) actually remove
things from containers! Instead you have to pass its results into
container::erase in order to do anything at all.
Fixes#17579, and in my testing at least, the strange crashes
and heap corruptions.
Includes support for new I219 device families.
Taken from the 13.1 releng branch (currently on "beta 2" status.)
Tested in QEMU and VMware. The "e1000" device works OK in QEMU,
"e1000e" does not anymore, but reportedly the FreeBSD devs say
it does on bare metal, so this is probably a QEMU bug (it doesn't
seem to be a commonly used device.)
This reverts commit 8497a2cc28.
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.)
This is a bit excessive: a file with a B_MINI_ICON resource of the wrong
size should not result in crashing Tracker, the resource should simply
be ignored.
Fixes#17668.
Change-Id: I55a210eb829e568d254d8ab569720145c0ea5a09
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5115
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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>
