ASID allocation is not supported yet, so always use ASID 0 for user pages for now.
Change-Id: I021e77dae692c22984bc625dd0588362bece45b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6698
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
gcc 13 is confused by the custom bitset implementation, so use the C++
standard one instead.
However, this results in including the C++ <string> header in kernel
code. This doesn't work for gcc2, because of two problems:
- That header includes a declaration of atomic_add that doesn't match
the one in SupportsDefs.h (which can in some cases replace the function
with a #define for an inline version). Adjust the header to use the
be a problem because it creates a risk of circular inclusions.
Standard C++ headers shouldn't depend on BeAPI ones.
- It also leads to the inclusion of iostream which defined lock and
unlock functions in the global namespace. We don't want these, and they
are not part of the C++ standard, so just remove them.
Ideally we could use std::hash for the GetHashCode implementation, but
that doesn't work because it depends on an helper function that's in
libstdc++, and we can't link that from kernel add-ons.
Change-Id: Iee07280beb4dddf7a9b6160e37f3b816e4de89ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6663
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Previously this just turned the rw_lock into the equivalent of a
recursive_lock, which meant that reader vs. writer assertions
were of no use.
Now, we have a per-thread static array which stores the held read
locks, allowing ASSERT_READ_LOCKED_RW_LOCK to work properly,
and allowing multiple readers to be active at a time.
This probably should still remain disabled even on nightly builds,
but at least it's much more useful as a debugging tool than it was
beforehand.
Change-Id: I386b2bc2ada8df42f4ab11a05563ef22af58e77f
GCC 13 is more strict about what C++ features are available in a freestanding
(= build without standard library) build. The `stdlib.h` and `math.h` headers
are redefined as part of libstdc++. If the object is built as freestanding, it
should be assumed that none of the standard library functions are available.
The solution in Haiku has been to add part of the standard library into the
kernel shared object. The method of exposing them has been to allow the
use of `stdlib.h` and `math.h` in the kernel and in kernel add-ons.
This change allows that approach to continue. What it does, is that it defines
specific headers which will be picked up when a module is built using private
kernel headers. When building for the kernel (or for the boot module), it will
bypass GCC 13's libstdc++ default behaviour of not including the POSIX/platform
header with all the function definitions.
An alternative to be considered for the longer term is to specifically define
the parts of the C/C++ standard library that is available in the kernel in
these headers, or create custom headers when building kernel modules (which is
how Linux approaches it).
Change-Id: Icab4614f642219fa77732b02401570708ee9a963
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6645
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
- Resize the `page_protections` array in `cut_area` and also shift
the bits if necessary.
- Set the correct protection array as well as the real page
protections for the second area produced by `cut_area`.
Change-Id: I62293480487e869420ebe5a3bc729cec2a14c687
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6395
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This requires the introduction of the flag B_USER_MUTEX_SHARED, and then
actually using the SHARED flags in pthread structures to determine when
it should be passed through.
This commit still uses wired memory even for per-team contexts.
That will change in the next commit.
GLTeapot FPS seems about the same.
Change-Id: I749a00dcea1531e113a65299b6d6610f57511fcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6602
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Introduce SWDBM flag similarly to the arm64 port
* Reuse TEX[2] for SWDBM flag which should be availble
to be used by the operating system if TEX remap
is enabled.
* Introduce SetAndClearPageTableEntryFlags for updating
accessed and modified flags atomically
* Startup sequence is handled similarly to accessed flag, i.e.
set Modified flag in initially mapped pages in bootloader and early map.
* Once the kernel initialization has progressed enough,
pages are mapped as read-only and modified flag handling is done
in the page fault handler.
Change-Id: I8f761e2c6325d1b91481abd569d5e8befded0761
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6518
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Condition variables are now a pretty common way the kernel blocks threads.
That means the "threads" command was getting difficult to navigate, since
at any given time, a lot of threads could be blocked on "cvar".
Now we try (carefully, because it could fault!) to fetch the first 4
characters of the "type" name and display then. This suffices to
distinguish the most common object block types in the list at a glance
(e.g. "cvar:port" for port reads, the most common.)
Change-Id: I94f4b59fd78b7ebdce913944551a5e98f0ca2e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows to see the display in Screen preferences, and know its DPI
and physical size (as much as EDID data can be trusted). This
information could be used to compute the default font size, for example,
so it's important that all drivers provide it whenever possible.
Change-Id: Ic3d04e53cf5fcb24e22d35661d2b364a257947da
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6576
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Suppose the following scenario:
1. Thread A holds a mutex.
2. Thread B goes to acquire the mutex, winds up in kernel waiting.
3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)
4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.
5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.
6. Thread A, suspended back in step 3, resumes.
Now we encounter the problem. Under the previous code, the following
would occur.
7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!
8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!
The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.
Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.
That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.
Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.
Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.
Fixes#18436.
Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Pages should not be marked as accessed when initially mapping them.
However, there's a short interval during kernel startup when new pages
are mapped but the fault handler is not installed yet.
Therefore, we set Accessed Flag to 1 in early_map.
Once the kernel initialization has progressed enough, we start mapping
new pages with Accessed Flag set to 0.
The chicken and egg problem of initially mapping the vector page is
tackled by preallocating the vector page in the boot loader.
Change-Id: Ie3be4f81812d7a090af57e8c79420598d16182b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6450
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We must do this to prevent lock order inversion: when busses are
initialized, they are started by the (locked) device manager, and
then acquire the explore lock. We must do the same in Explore itself,
for when called by the explore thread, we would otherwise first acquire
the explore lock, then (when publishing new nodes) acquire the device lock.
Should fix#18421 and #18393.
- Resize the `page_protections` array in `cut_area` and also shift
the bits if necessary.
- Set the correct protection array as well as the real page
protections for the second area produced by `cut_area`.
Change-Id: I62293480487e828970ebe5a3bc729cec2a14c687
- Add support for retrieving the `siginfo_t` structure of a signal
event from the Debugger API.
- Add code to `strace` to display this information every time a
signal event occurs, similar to the Linux `strace` tool.
Change-Id: If4e92bbae049ee0b52efaf9fc911d66511da62f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6393
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Introduce a new utility method, "generic_memcpy", which takes
generic_addr_t plus indications of whether these specify virtual or
physical addresses (and potentially user addresess) and calls the
appropriate memcpy variant depending.
All bus drivers adjusted to support this at once. We don't actually
take advantage of the physical addresses in any way (yet), as USB
controllers have some pretty specific requirements that would have
to be carefully validated to use these directly.
All bus drivers tested and confirmed to still be working.
Change-Id: I66326667e148091147bb2b3d0843a26fb7e5bda6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6479
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way it is more easily accessed from drivers outside the kernel,
which it soon will be, without having to add an explicit UseHeaders.
(The drivers that use it already all use the IOScheduler.)
No functional change.
Change-Id: Ibc2d2678e37d9d7ab73391cb17b72cca86f92132
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6477
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Before the PCI refactor, PCI initialization/enumeration occurred
immediately after the PCI module was loaded, and so by the time
we got to IOAPIC initialization, it was already complete.
After the refactor, PCI enumeration is deferred until slightly later,
and so we would try to initialize IO-APICs without knowing PCI
information. This would fail, as read_irq_routing_table needs to
have that available.
Hopefully fixes#18425, #18393, #18398.
Change-Id: I1e4b06367da26eeb10085a1c6322ed39885b632b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6476
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Stored the additional start time of each team, expressed by
milliseconds since boot.
- Added more fields to the `team_info` structure. These field
include those provided by the `get_extended_team_info` syscall as
well as the newly introduced `start_time`.
- Extended the `_kern_get_team_info` system call to receive an
additional `size_t` argument. If this size is smaller than or
equal to the size of the old `team_info` structure, the newly
added attributes will not be retrieved.
Change-Id: I22ee6b91ad2ee3b66a7f770036c79a718c5f115c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6390
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
This new driver uses the "generic" TTY layer, unlike the old driver
which had its own implementation (which the generic module was derived
from, originally.)
The remaining bits of support for controlling TTYs is added to the kernel &
generic layer at the same time, which should allow for serial interfaces
to be controlling terminals now, as well.
Tested with bash, nano, vim; all seems to still be working as expected.
I want to use this in at least 2 third-party applications. I think it's
time to make it shared?
Change-Id: I855a59aab4ad6d47d77cf2901cb3dfc34c108059
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6296
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
THREAD_BLOCK_TYPE_OTHER implies the "object" pointer in the
wait information is a string. But sometimes we want to pass
through objects which are not strings, for inspection in KDL.
* Make some code common in Insert.
* Remove unneeded logic from InsertAfter and just call the base Insert.
InsertBefore does this, already.
* Synchronize Insert code and APIs in the fs_shell DoublyLinkedList.
Removing it outright would cause implicit conversions and then the other
variant being called, which would create invalid lists. So make it private
so that any attempts to use it will create errors at compile-time.
Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.
A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.
This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).
On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*
Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.
My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.
Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
Change-Id: Ia16e66a7bdac37019e6256405b9f10024909c69a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6215
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The kernel heap only uses object caches for objects up to size 8192.
Larger allocations have to go through the raw allocator. That can
get pretty expensive.
Adding instrumentation around the malloc/free calls in this function
showed that on my machine, some 596ms during boot were spent on
*malloc/free alone*, all else aside. After this change, we are at
around 110ms, or a >5x improvement. Running an fgrep -R on /system/
after boot increased the cumulative time in memory functions to over
5 seconds, while after this change it is "only" 1170ms.
Honestly, it seems like the object depots should be able to be faster
than that, even if this function is called thousands of times. But that
is a problem for a different investigation.
It would be even faster for every consumer of this data in
packagefs just allocated one set of buffers up front, or at least
for a single "read session", but plumbing that all the way
through the myriad abstractions of the Package Kit will
not be easy, and is left for another time, as well.
"Newer" synaptics touchpad support a new mode where they can report more
information to the host. In this mode, there is a different packet
format for tracking extra data from the touchpad, including a wheel
encoder (mousewheel) if available, and multitouch finger tracking.
This mode is documented in the Synaptics touchpad interfacing guide
(Synaptics document 511-000275-01 Rev. B), but was not yet implemented
in our driver.
It should help with detecting multiple fingers, or finger position on
clickpads to determine right or left click.
This change implements the following items from the Synaptics
interfacing guide:
- Cleanup and clarify the code for features detection to properly report
clickpads
- Enable "extended W" mode if supported
- Process extended W values 0 (mouse wheels, reported in the
touchpad_event structure and could be used by input_server for
scrolling), 1 (secondary finger), and 2 (finger count)
- Fix handling of wValue, which is not always a finger width
- Add handling of vValuen which indicates the finger width when wValue
doesn't
Overall, this should provide the movement_maker with a better picture of
what's happening.
Also improve tracing to show received packets and the corresponding
WValue since that's an important value in identifying which type of
packet it is.
Unfortunately I currently don't have a laptop with synaptics touchpad to
test this with.
Change-Id: If334392f4eb2a146955f6c8c897f0ab64d79b8d9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4425
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: nephele <nep@packageloss.eu>
This is duplicated across multiple filesystems, and could probably be
used in more still.
Adjusted only BFS, EXT2, and NTFS in this commit, as they are the ones
which make use of fs_ops_support.h already and thus need to be modified
to avoid duplicate-definition errors.
Also tweak next_dirent to support being built under fs_shell.
(Possibly we should define ASSERT there, though?)
Compute a font size that just fits the available space, instead of using
an arbitrary scaling. This makes the code adjust to any font and any UI
size.
Select the appropriate font using a binary search, which will need only
a few attempts (I think 6 font sizes will be tried at the default
config)
Change-Id: Ie3b8678678c0d940981f1785418aa8ab354d01c5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3893
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This is needed to fix usage of POKE_GET_PHYSICAL_ADDRESS on
x86 32 bits (with PAE).
Change-Id: Ic00185ec7fcf9b6666ad6169a752d8b8edd2b61b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5975
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This patch adds an API call to BFont, called LoadFont, that
takes a string path to a font file. The user fonts are managed
via a new class called AppFontManager that inherits from the base
class FontManagerBase but adds the methods to add and remove user
fonts from disk or memory. There is also a new method called UnloadFont
to remove a user font, but on exit of an app all user fonts should be
automatically cleaned up.
Global/system fonts are managed by the GlobalFontManager, which is
a new class that also inherits from the base class FontManagerBase,
replacing the old "FontManager" class.
A maximum of 128 user fonts may be loaded, and memory fonts
may not exceed 20MB.
There's also an overloaded version of LoadFont that accepts
an area_id and loads the font from memory. A size and offset may
optionally be provided to allow for an area that contains more
than just a font.
Change-Id: I6add42bdf0c0cefc0e2e2a4984fd848c3e7269e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4790
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* We needed this previously due to our gcc2 compiled kernel.
* Now that our kernel is always latest gcc, we can move to the
c++20 syntax for inline assignment.
* Improves compatibility with clang, less GNU-specific stuff
Change-Id: Ib7272a0a52554a31e9a0e788fd3f031db9049795
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5898
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
we detect basically the cpu info before loading the microcode,
to be able to detect the vendor, and avoid any update on hypervisor.
I couldn't test because my cpu doesn't have any update available.
Change-Id: I6aea830158423b3ee13b640be8a788fc9041e23c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5859
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
tested on Zen2 (Ryzen 3 5300U)
This support was submitted in October for inclusion in Linux.
Haiku supports only two profiles. We could probably add some more, and let the driver says which it supports.
Change-Id: Id7754b445bc32a691d58a1e4af630351562abc22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5826
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
remove the yarrow module. the hardware modules can push entropy with queue_randomness().
virtio_rng will now push entropy every 300 seconds.
helps with #14937
Change-Id: If76c5deabf61dc616a0e051332f44b89deb6b8a1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5824
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There's currently no way for an application to convert between view and
drawing coordinates with a drawing states stack without keeping track of
all the transformations itself, which is not very convenient for helper
or library functions.
Handle other spaces too, for good measure.
Change-Id: Ic8404a1c111e273fff1eebf2f9f59f58246b796c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5775
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fix regression that building Haiku on 32 bit Haiku become not possible.
Change-Id: I527a8c3bc3ad4744d5515a76888d5cac06293cbe
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5750
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The overall design does not deviate much from my proof of concept [2] and that still makes a good read to
understanding the overall architecture. If you want to get a sense of how it is built up, the API comes with
full doxygen documentation for the public API [3], and I have also done a PoC change for HaikuDepot which is
useful as an illustration on what the impact for the user of the new library is. [4] There is also a test suite
that may give some insight into the day to day ergonomics of the API [5].
The current state is that I am fairly confident that many HTTP requests will actually work, but I do expect
rough edges with a protocol with this many diverse implementations. There is also a list of features yet to be
implemented on Trac [6]. Additionally, I still want/need to do performance testing.
The goal of merging the kit right now is to start making it available for more uses, and through that also give
a chance to shape its future. There are also some design decisions that need review, most notably I expect some
discussion around the uses of C++ 17 idioms (like std::optional and std::string_view) and around the use of
exceptions for error handling.
The impact of merging right now should be near zero: the netservices2 kit lives in its own header space, and
builds into its own static library (libnetservices2.a). It is not yet used in any of the apps in our
repository.
The branch does remove the deprecated services kit from the libnetapi.so library, though it leaves
libnetservices.a intact. After our previous announcement to remove it after beta 3, this should be expected.
[2] https://github.com/nielx/haiku-netservices-rfc/tree/exceptions
[3] https://git.haiku-os.org/haiku/tree/docs/user/netservices?h=dev/netservices
[4] https://review.haiku-os.org/c/haiku/+/5692
[5] https://git.haiku-os.org/haiku/tree/src/tests/kits/net/netservices2?h=dev/netservices
[6] https://dev.haiku-os.org/wiki/Development/NetServices2
Change-Id: I5d0b7e2619699f39a2506588417b57391f0f5cc2
* Nothing in the tree and few things outside it used BIG_{SPACING|INSETS};
it seems a value of 15px (at default font size) is not that useful.
There are, however, a lot of things around the tree that use multiples
of 20px. So, make BIG be that, with the intent to replace those
with BIG directly.
* Introduce CORNER_{SPACING|INSETS}. There are a lot of applications
(e.g. Tracker, Terminal, Debugger etc.) which use scroll bar width/height
to metrically align controls with the window frame or with some other
control which contains scroll bars. Rather than have to invoke
BScrollBar or BControlLook directly to get the value, we should just
derive the size of scrollbars from a spacing constant instead
and get rid of the custom function. (For now it is just replaced.)
This reuses the old values for BIG, as it is equal to 14px at default.
* Introduce BORDER_{SPACING|INSETS}. This is equal to the typical border
size of 1px at default font size (or lower) and uses floor() instead of
ciel() to compute what the size should be (i.e. it will remain 1px
at 150%/18pt and only go up at 200%/24pt.) This will allow a lot of
the hardcoded border sizes around the tree and elsewhere to use
ComposeSpacing() instead.
Change-Id: Iaea3fa30364859888e816a9d61ac156268d70758
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5702
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: nephele <nep@packageloss.eu>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This methods do not need DoublyLinkedList class state.
sGetLink field that actually implement GetPrevious/GetNext methods is already static.
Change-Id: Ie0b40f7f1b72d640d75403905b8944666874dc87
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5796
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit formats all the netservices2 code with the `haiku-format` tool from
https://github.com/owenca/haiku-format (commit aa7408e), with the following
customizations:
* SpaceBeforeRangeBasedForLoopColon is set to false
* Braces before a catch block are not wrapped
* Most headers, except for ExclusiveBorrow.h, have been manually reformatted
to adhere to Haiku's header format (issue #19 in the repository)
Change-Id: I693c4515cf26402e48f35d1213ab6d5fcf14bd1e
- These two functions imported for Linux/BSD compability.
Signed-off-by: Han Pengfei <pengphei@qq.com>
Change-Id: I3e9cada26f1ed043bfaed83e8185dcfff3bd71e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5746
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
for legacy and new drivers.
This is an opcode for ioctl that can be used on almost any device entry found in /dev.
When used, ioctl will fill a buffer with the absolute path to the driver file that is
being used by the device.
This opcode was available in BeOS R5, though remained unimplemented in Haiku since
the introduction of the Device Manager almost two decades ago.
Original change by Jacob Secunda.
Change-Id: Ic49141b677b4158a63918459d4048450c825447c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5078
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* This seems to be required when building the DriveEncryption kernel
driver with gcc 11.2 on x86-64, at least.
Change-Id: Ie1ae09435dd912021957e64d4b9a3e7b05913c33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5742
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
also only provide a default name for partition containing a file system
fix#17958
Change-Id: Ib5a8928dc5272a400a99aa05b792201f3a6a2c7d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This takes care of making sure the dirent buffer is properly aligned,
which it needs to be on some platforms (SPARC, ARM, etc.)
Change-Id: I9a6352b1e654c090a200770d51f96511ee024a99
only scsi_disk checks the actual value, other drivers take the logical block size.
This change reports the physical block size from the disk rather than the block
size used by IDE/SATA/SCSI commands. On typical modern SATA disks, the SATA
commands will use 512 byte blocks, but the disk will actually read and write
4K blocks internally. This is only of importance for partition alignment for DriveSetup,
and is independant of file systems or partitioning systems. This could also influence
the recommended block size for some file systems.
Change-Id: Id0f2e22659e89fcef64c1f8d04f81cd68995e01f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5667
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This will give the same result as fs_stat_dev, so the filesystems will
have the same name everywhere.
Change-Id: Ic684142efaeb2c16b393f3f3e5c9c3010a054b30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5636
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This avoids introducing an entirely custom hook in FUSE.
It uses the ioctl hook in an unconventional way (calling it with no
valid fuse_file_info) but this can be fixed if a filesystem requires it
(by opening a file handle on /, doing the ioctl, then closing again).
An updated version of fusesmb-haiku is available and confirmed working:
https://github.com/haikuarchives/fusesmb-haiku
Change-Id: If1268113874363fa035e5340be75e9f5198216d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5199
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Not referenced in any Jamfile, does not compile, untouched since
2003 except for a few coding style and cppcheck fixes. The functionality
is implemented elsewhere in the disk device manager and userland
filesystem add-ons for DriveSetup.
Change-Id: I5ebe125931c8d4410c2d335f9d6c0e32008f038b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5637
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* 90% of our logs start with some context on what is
generating a log message (thing:)
* Things following this logging model however do "thing [time"
which is inconsistent
* Being consistent will allow us to start scanning logs in a
smart way and try to analyze patterns of what is throwing
errors, etc in an automatic way.
aka /^(service/driver/etc)\:/
Change-Id: I1ef2df4f17f70f858a485554a4e8a3f87f1a69c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5568
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Oscar Lesta <oscar.lesta@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
