OpenBSD's and FreeBSD's kernel APIs are very similar, but there are
still some differences. Fortunately these are small enough that we
can take care of most of them with a header-only shim layer.
(The files and functions implemented by this commit were implemented
and tested against the modules and drivers imported and adapted in
the following commits. Some of this took quite a bit of time to get
right, especially where the APIs have diverged in very subtle ways.)
Most of these changes however add things that FreeBSD has (with a few
exceptions noted in comments) which the OpenBSD shim layer merely needs
to make use of.
(FreeBSD used to have support for IFF_NEEDSGIANT but removed it. The
support instated here is very similar to what FreeBSD used to have.)
* Have FindPanel::AttachedToWindow check to see if a MIME type is
already selected, before it sets MIME type to the default value.
* Fixes#14946.
Change-Id: Iab3b9058bbc3ef1f055475ed54a72d4032643632
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5357
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
IEEE 802.11 has its own maximum MTU which is smaller than PAGESIZE
but larger than the ETHERMTU default. So we now attempt to set this
as well. In doing so, refactor the set into a loop based off an array
of possible MTUs.
Before ca6a44c133, this function returned
whatever amount of the buffer it could and silently discarded the rest.
After that change and before this one, it would refuse to return anything,
which meant that as soon as we got one packet too large to handle,
we would never receive any more packets (and the errors displayed in
e.g. ifconfig would go up forever.)
Now, we discard too-large packets so RX will not stall completely
and still return E2BIG (so error counts will go up), but we also
print an error to syslog, so that precisely what has gone wrong
will be easily known.
"ticks" is the name of the global variable indicating time since
system start; "_ticks" is the local variable. The confusion between
the two caused every callout to be invoked as soon as it was instantiated.
I am pretty surprised this was not noticed before. I only discovered
it just now while working on the OpenBSD WiFi driver ports. Seems
it has been broken like this for multiple years...
In some circumstances, we can wind up iterating on requests
by recursing through this function once per "iteration" due to
how vfs_synchronous_io works. This can run out of stack, as
was seen in #9900 and potentially other tickets.
An initial attempt was made to fix the problem in hrev45906,
but it was quickly reverted because it seems to have broken
I/O for all devices that do not support the "IO" hook.
This solution is much simpler: the VFS layer already can handle
vnodes' IO hooks returning B_UNSUPPORTED and then falling back
to synchronous I/O just as if they had no IO hook at all.
This should hopefully cause iteration to occur without recursion.
Tested by booting off a USB drive (the usb_disk driver does not
support the IO hook, so all requests must be translated.)
May fix#9900.
Strange KDLs showed up on at least one system with this driver after
the enabling of jumbo frames, so it seems probable that was the cause.
Disable MTU changes to hopefully prevent this problem for now.
Should hopefully stop #17766.
Performs the increment of the view counter
after a delay of three seconds; otherwise
a number of "false views" can be stored as
people use keyboard navigation.
Relates to #16879
Change-Id: I6f3440e1e3132c832cd807e48105022d22df9abf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5356
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
this needed for dp aux before skylake, only for DP A (eDP).
should help with #17771
Change-Id: I4bdcca1fdc05294fb5b56c5c96164b6936a5881e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5355
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Use with --sysroot /path/to/sysroot; useful for CI
environments and cross-building.
Change-Id: I27a93a5d209cd5324591587e85fce9b47c18172d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5318
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
As the TODO comment noted, msg_iov has already been copied to the kernel
at this point (it is done in the syscall handler), so we do not need to
use the user memory access functions.
(I verified that the iovecs passed from userland are indeed copied to
the kernel, but I did not find anything that actually posts more than
a single iov, so this is not tested especially thoroughly.)
Create a utility function which performs all necessary checks,
allocates memory, and copies the structures, and then make use of it
in the three places in the kernel which did all this manually.
None of them were previously complete: the fd and socket code only
checked iov_base and not iov_len, while the port code did not check
anything at all.
Part of #14961.
We do not access these buffers directly here but pass them deeper
into the kernel, where they may be used in IO operations that do
not invoke user_* functions at all, so we have to validate them fully here.
Part of #14961.
It has more general use than just in the VM code; basically anything
which receives buffers from userland should be invoking this if it
does anything besides user_memcpy (which alreay does it.)
These were completely rewritten by me some years ago and contain nothing
from Hugo or Colin anymore.
Change-Id: I07f95b79c08f93b7630f73b6ff60634e3fc95599
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5353
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This has been missing since the rewrite in 26b95c15f2.
Until now it seems to not have been a problem since buffer sizes
were generally small enough and did not cross page boundaries due
to alignment guarantees. However, now that we have enabled jumbo
frames by default, some drivers do hit DMA limits without bouncing,
as these frames cross pages.
So, now we implement a basic bouncing system. Unlike FreeBSD which
maintains a global "bounce pages" cache that it pulls from,
we use per-dmamap bounce buffers, lazily allocated only if needed.
I tested this by forcing all non-"prohibited" dmamaps to bounce all
transactions, and the rtl81xx driver still worked that way (though
not all drivers may as they have expectations about contiguously
allocated memory never getting bounced.)
This should fix#17763. Hopefully it will also fix#17766 as well.
* 10fd7e3817
"Force maximum payload size to 128 bytes for AR816X/AR817x as it triggers"
* could help for #16978
Change-Id: I626e364adcabaa9b3d7e4c1078067c1d82c7d4e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5340
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The MainWindow itself was a BReferencable via a listener
virtual class. It looks like the error has come from a
conflict between the MainWindow's own deletion and the
state of the reference count. This change moves the
listener / BReferencable out of the MainWindow so that
the lifecycle of the BReferenable can be managed
correctly.
A further problem here is that the new listener
was leaked from the MainWindow class on shutdown.
To resolve this problem requires a considerable
change to the "process coordinator" system.
Fixes#17689
Change-Id: I7230843ba05537015f4a597b4a616b96c6db3dde
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5285
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
These were output to the root of the generated directory. There should
be nothing there except the final Haiku image.
Fixes#16750.
Change-Id: I132de939c70197c3f7cc306ac371965a0b7f38b3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5346
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
