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>
Some symbols were available because they were reexported by haikuwebkit
1.8.2, but they won't be exported anymore in the next releases. So we
need to link to libnetservices.a directly, and link to it before the .so
files to make sure the symbols from the static library are used.
If there are undefined symbols, we can't load the kernel (the bootloader
complains about missing relocations). It makes sense to not allow that
at compile time.
Change-Id: I430bebada16544ffa8be293cd6c075338970d8ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4668
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This replaces the previous round-robin system. It should reduce
lock contention on multi-core systems, with potential other
benefits depending on drive behavior.
FreeBSD's NVMe driver does basically the same thing.
In most cases we don't need to use the complete display_mode struct and
we just need the timings. This will avoid future confusion between the
virtual width/height and the actual display timings, if we implement
scrolling someday.
Change-Id: I6c4430b84130b956a47ea0a01afb0843f5a34fd2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4665
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Apparently my comment about the width and height being swapped in this
register was not visible enough, so I make it a bit more obvious by
adding some uppercase.
Change-Id: I27621032d071ed09f82aa109f37482178351db04
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4664
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add a column to the table to show the publish
date. Also add text on the featured packages
view to show the publish date. Supports
sorting.
Fixes #13006
Change-Id: I19d9bc5bf7f44b5673c2ade5d00de8fdadbe1b06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4649
Reviewed-by: humdinger <humdingerb@gmail.com>
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The upcoming change to use zstd by default will make the -z no-argument
variant obsolete, so instead we need to support passing "zstd" or "zlib"
to actually indicate the compression method we want to use.
BZstdCompressionAlgorithm already has these #ifdefs and will
return error codes appropriately if built without libzstd,
so we do not need to check again inside the Package Kit.
This should not break the no-zstd build (well, it is broken
somewhat right now anyway, but this will not break it further),
and it simplifies logic somewhat.
This way, we get the user's environment variables, and so should
input_server, which is started by app_server.
This should, after 6 years, fix #12534. We may need to revisit this
when/if we add multiuser support, but that is a problem for another day.
Change-Id: I04698306bc68a585acd232e9f9d29c50bc170a1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Refactors so that we look for a codec subsystem ID, then the
Audio Function Group subsystem ID if not found.
* Moves the order around a bit so that the quirks are set early
enough.
* Also adds a quirk for MacBookAir 6,2, allows speakers to work.
Change-Id: I4c64f96936a82a5d7187d86d8558f28516fd4ecb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4654
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We still do not know if the accelerant buffers are graphics memory or not,
but in my testing (on the VESA driver), the only time I could get _CopyRect
to be called was where the buffer was in fact not graphics memory.
So that should provide a performance improvement there.
On the other end of things, this should resolve unaligned video memory
access problems on RISCV, and potentially other platforms, as gfxcpy32
did not attempt to align pointers; it should also improve performance
as memcpy will usually be faster than our custom gfxcpy here.
Most of this code has not been touched since 2006 or so.
Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315
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>
It just causes confusion and is wrong in the case where double buffering
status changed during the object lifetime.
Change-Id: Ia1a9ae3f5a1b1b7d521b79c7d1c7be92cef60a06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4633
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
libtermcap was deprecated in favor of terminfo in 2013; the library was
removed then, and this file was only left because not all optional
packages had yet been rebuilt against ncurses. Well, that has now
long been completed, and indeed all applications continue to function
even after removing /etc/termcap.
In case any legacy applications that I have missed still do need it,
it should be provided by HaikuPorts and not Haiku itself.
These are better here than in my bash history...
Change-Id: Iab8940f4efed950e26a8bad29cb8954464270e8f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4645
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On Sparc Openboot, we get allocated a stack of only 8 kilobytes, and
each called function costs at least 176 bytes for the stack frame.
This means we need to be more careful than usual about stack usage. Move
some large-ish allocations off the stack by either making them static,
or allocated dynamically.
Add a compiler flag to error on functions which use too much stack. The
threshold is at 1023 bytes, because that's what allowed me to find the
two functions that were causing a stack overflow (open_from and
_ParseActivatedPackagesFile)
Change-Id: Ia0d13a9247e1a3fff4ce654bdffd6edb16e7cbc7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2371
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These are helper functions for long double math. On sparc there is no
hardware implementation of long double instructions, and the ABI defines
these methods which must be part of the C library. GCC calls the methods
directly in its generated code.
They were already added to libroot, but they also need to be in the
stub, which is used during bootstrapping to link mpfr (during the
target gcc build).
I put these in a separate file because I assume the generation of the
stubs file from the real libroot.so will usually not be run on sparc,
and will not include these symbols otherwise. This may become a problem
if libroot for different architectures starts to diverge further.
Change-Id: I6070394c685fee35b3dc12a507f5a6271571b993
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4636
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way it becomes much easier to write multiple console implementations
in one bootloader.
Tested for bios_ia32 and efi.
Change-Id: I67134f5c3de109b15d46898864ba7f51c6592afc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4642
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Most importantly include zstd, which is a new requirement for the
bootstrap build.
Change-Id: I981401e7d70fb7e1befaf7fc37f2fddc6d7e327d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4635
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is an internal ICU library, used by their command line tools only.
libbe (or anything in Haiku sources) does not need to link to it.
Change-Id: Id322572c6833c225d5501a7e9520dd3dc82934f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4634
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Delete dropped out networks.
* Add in newly discovered networks.
* Add static (aka class) compare method to WirelessNetworkMenuItem
that is used to sort items by signal strength descending.
Add == operator to wireless_network struct to determine if
existing items have a known network attached.
Remove the non-network items from the menu, save them, sort
network menu items, then add non-network items back into the
menu.
Update NetworkStatus preflet to use same compare method as Network
preflet. signal_strength_compare function had a bool return value
instead of int which worked to sort items the first time, but does
not work on successive compares.
By not deleting and recreating the menu items each Pulse(),
the Network preflet no longer crashes on update. The menu flashes
on update still but doesn't crash.
Fixes #12024
Change-Id: Ie5b22cea4e66350b9c5df8e3b8de266ede50ad6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4243
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
... methods which call the respective methods in BList.
These convinience methods allow you to sort a menu of menu items
via a compare function, swap two menu items, or move a menu item
to a new index. Update items layout if menu is open.
Previously there was no easy way to rearrange menu items in a menu.
Change-Id: Ice3d6e5404e895196d8bd32d696dce7c55bd72d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4296
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The other Atheros drivers are "atheros813x" and "atheroswifi",
so renaming this one (which is the oldest of the set) to match
the other two makes sense.
This is the driver for Intel's new line of desktop-class ethernet
controllers, from FreeBSD. Not yet included in the builds as it
is untested.
Part of #17212.
Now that there is also a "tap" driver in here, and the WiFi drivers
are also in a subdirectory, moving the physical ethernet device drivers
to a subdirectory also makes sense.
(Briefly) discussed on the mailing lists.
This cuts out almost 40,000 lines of these headers. (I did something similar
in the atheroswifi AR93xx/94xx driver when importing it from FreeBSD,
which had a lot more than 40,000 lines.)
The code in this module was derived from the one in driver/tty. However,
the driver uses a shared lock between the master and slave side of a
TTY, and this was changed to use two separate locks. The approach with
two locks does not work. It seems the change was unfinished and the
second TTY was never locked. But attempting to lock it will result in
lock inversion problems, unless we do complicated things (try to find
which of the two TTY is the master side, and lock that first, for
example). It is simpler to restore the shared lock as used in the
driver.
To set up the shared lock, I modified the tty_create function to take a
pointer to the master TTY when creating the slave. Maybe it makes more
sense to create both sides in the same call, create_tty_pair?
However, this does not work as easily as I wanted, because there is some
recursion going on: at least in one case, the tty_control function is
calling the driver's tty_service function, which in turns attempts to
call back into tty_control for the "other side" TTY. To handle this
case, replace the mutex with a recursive_lock.
Fixes #17091, where the root problem was access to
other_tty->select_pool without locking. This was also made unconvenient
to debug because select_pool objects are self-deleting, when the last
item in the pool is removed. As a result, the code accessing it without
log would suddenly find out that the data it was accessing had been
freed and erased.
This also makes the TTY code in driver/tty and generic/tty a bit more
similar than it was before, and brings us one step closer to merging the
two together. There are still two main differences and I don't know
enough about TTY to decide if they are important, and which version
should be kept:
- The driver has extra code for "background" read and write. I don't
know what this is used for.
- The driver has a single "settings" instance shared by a master and
slave TTY, while the module has two separate instances, but seems to
copy one to the other. I'm not sure which approach is correct.
Change-Id: Ie2daddd027859ce32ba395af76b4f109f8b984b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4604
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There is no need to construct and destruct nested objects. The new and
delete calls on the struct will take care of it. However, some fields
have C functions for construction/destruction and these should be
called.
Change-Id: I09d5930f499ef3fa4ff580d482c682172b00b6a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4603
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Suggested by axeld on the mailing list a while back.
strlcpy/strlcat NULL-terminate within the passed buffer size,
so we have no need to subtract 1 here.
The changes for iflib reorganized some things that these drivers used,
so here we upgrade them as well.
One new chipset is supported in rtl81xx, the rest should all just be
API changes.
In 47404f12f2, a MemoryDeleter was added
to manage this memory instead of doing it manually; most of the free()s
were removed in that commit, but these were somehow missed.
It will be needed in the VESA driver to locate things in the VESA BIOS.
Change-Id: Iab42886beb99414fec4d1ad99a08299be679b4d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4623
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These will be needed to implement custom modes in the VESA driver.
Change-Id: I9b52de691baa14e1f1a3ccce500ced9bb040b113
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4622
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This will be used for live patching of the VESA BIOS.
Change-Id: I66c2dfd950262b5ba4d1e7b424eac46f0695297a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4621
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should resolve the problems where the framebuffer driver was
getting picked instead of the "real" graphics driver, when available,
which led to the framebuffer driver getting merged back into the VESA
driver.
Change-Id: I4ad00d2ac3b5dda34aa63f8691d4cbb85e4f6bb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4616
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit a0db7ef272.
This reverts commit 40cdf7d607.
This reverts commit 2ff22d6734.
This reverts commit b9eacd390d.
This partially reverts commit 5ae7ac5fd9.
This was all added in the run-up to the removal of the framebuffer driver,
or was added since then to enhance framebuffer-only support in that driver.
Change-Id: I32ab8199f22cf6846545ae19e943c98012b2a1d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4615
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 72fc5e6a71.
They were removed because app_server often picked them instead of
a better graphics driver, and fallbacks merged into VESA instead.
That seems to have created more problems than it solved, in the long run,
and so the intent now is to change app_server to understand the
framebuffer driver as a fallback one instead.
Change-Id: I6edd97fb29ed2b9c13c6c540569695c8426ecfd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4614
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Do not rely on symbols overriding other symbols, which is
not a safe assumption and not good practice either. Instead,
move all methods into FlatControlLook.
* Reorganize class structures somewhat.
* Remove unused variables.
The bootloader is larger after adding zstd and needs more space now.
384 is the value used already on PPC and SPARC. Fixes generating
floppyboot archives for anyboot images following recent changes.
any ordering is legal, but some devices don't cope with what we do.
thus we reorder sack_permitted before timestamp, this doesn't cost us anything.
noticed by Sikk: https://dev.haiku-os.org/ticket/13681#comment:11
Change-Id: Ic2e1589945dd74e3034a653427a2ff45626b3a76
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4598
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Now that it is not used anywhere in the source tree following
previous commits.
Change-Id: Id2fc417a0658d09148e99587c613a928f1fbe4c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4611
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
B_FILE_NOT_FOUND was deprecated in BeOS R5 in favor of B_ENTRY_NOT_FOUND,
but it remained in Haiku and was never removed even conditionally, so
we have accumulated a number of usages of it.
This commit changes all the usages of it in new code, applications,
or anything else that BeOS applications will otherwise never see,
and so should be relatively safe.
* SetAttribute() will fail for read-only volumes.
* Duration() is called in playlist's Draw() method.
Since _CalculateDuration() is very expensive because it parses
file metadata, it causes visible drawing glitches and playlist is
almost unusable.
* Mitigates #15221. I don't consider this a fix because first draw
is still going to block for a long time, but at least scrolling
works smoothly now. Ideally, file metadata would be parsed
asynchronously in a separate thread and drawn as it becomes
available.
Change-Id: If198d61c77a7746bcc0e19b7caeed89ce829c247
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4597
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Currently I'm trying to debug things using the generic tty module, and I
can't use the command from the driver for that. I hope someday the
driver and module will use the same structure for the ttys and can share
the same command...
Change-Id: I167dab600ac8567368604f9b6463f787857f4d20
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4602
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The tty module started its life as a copy of the driver, and they
diverged over time as fixes and refactorings were not always brought to
both sides.
This commit does not improve the situation, but it tries to make the
two versions of the tty_private.h and tty.cpp files as similar as
possible to ease comparison.
Change-Id: I62255262b167ab81c9a0619c8f19b36b1a165fad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4601
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This variable is what debug_debugger_running() checks to determine
if the debugger is in fact running. Before this commit, it was not
set until *after* calling debugger module hooks; now it is called
before them.
This fixes #17302. The problem there was that the USB stack gained
an ASSERT(debug_debugger_running()) in code that is called in the
USB keyboard debug module initialization, which before this commit
would trip, and then enter an infinite loop as panic() does not work
during debugger startup. Now the assert is true and everything works
as it did before.
The 64-bit address accounting that was added used a hardcoded bar of 0,
which is not what we want here, so use the correct offsets instead.
Also account for sizes, too.
Otherwise legacy interrupts do not work at all on x86.
This fixes hrev55299, which contrary to the commit message,
did not "add" legacy interrupts support; it was already there,
and in fact that commit broke it on x86.
Had a look at the actual Debian os-prober (1.79) package and found
that they use /bin/sh as their shell for all their os-prober scripts.
So for Fedora and other downstream packages, someone must be going
through all the scripts and changing them to /usr/bin/sh. Switch
to the Debian variety since they're the upstream of everybody for this.
Change-Id: I2bed8cb133640861311061261ff0cae8ae6f2648
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4599
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This reverts commit 3e8376c6dd.
Reason for revert: Bootloader currently fails to load kernel
It should be added back once the kernel can start.
Change-Id: Iebefbf8681aff4dff09cef7b7eb832b61f7789c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4579
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
on x86, gcc emits a local reference to __stack_chk_fail_local
which can only be provided by a static library. as we don't have
a libroot_nonshared, we use libgcc from gcc, in which libssp_nonshared
was merged, from version 8.3.0_2019_05_24-11.
Change-Id: I22bf26dec5c1fe69a3915a923bd716a494f846ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4564
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
For inverse masks the real bounds rect is the canvas, as the points that
pass through are the ones not drawn.
Change-Id: I420a5eca419b215b55e4c2362e2c7646465a4cd3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4455
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
A few visual tests of clipping composition with different combinations of
layers with and without the inverse bit.
Change-Id: Icddb377508733463378f93b24075fd06e54ef2cb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4454
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Someone on the internet found out gcc only understand posix_memalign.
The alloc_align attribute may be applied to a function that returns
a pointer and takes at least one argument of an integer or enumerated
type. It indicates that the returned pointer is aligned on a boundary
given by the function argument at position.
Change-Id: I4b0af6ef3020da1fb460652117286193d5d72f1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4514
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
http://www.acme.com/software/thttpd/#releasenotes
Compiled on 32 and 64bit, ran PoorMan, and verified it served webpage and shows logs correctly.
Change-Id: I23fdf0f9910089aa8e24bb66ed7fb49b065b5577
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4404
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: Ifadd47204be1ec688017a567d43dca38c80bd1df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4431
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
- All network add-ons are now built with Werror, collapse the list to a
single entry
- Add a few busses add-ons that were not listed (to be checked and fixed if
needed)
Add one missing include and change variable declaration types to match comparison type.
Part of #9460
Change-Id: I95a12e5db11f95c2fd7c1906eaabdc5e21236cf1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4567
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Set first stack frame return address to
<commpage>commpage_thread_exit, so it will be called
when thread entry point returns.
Change-Id: Ide5cde8d4501eb7241e03ff4052174e984e78870
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4493
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
in a syscall, swapgs is always executed and can't be speculatively executed or bypassed.
it's also not needed on exception/interrupt exit, only on exception/interrupt entry.
follow-up on commit 84f6e2d39f by waddlesplash
(7aa47cace1)
Change-Id: I56de9526a1acd0075c4a12147ae782f0366dec52
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4557
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>
Done as part of #9460
Warnings related to comparison of integer expressions of different signedness
Change-Id: If5543db951b11aab1858a18a057b7d2e08ee2b42
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4503
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
When a library is not found, it is useful to know why it was linked in
by showing the previous link in the dependency chain. We had the
information available, but did not use it in the error message.
These were used in function_remapper.cpp but can be used elsewhere too,
so move them to a private header. Also use them for the stack protector
hidden function definition (probably not so useful since gcc2 doesn't
support using the stack protector anyway?).
The gcc2 way to make a symbol hidden is to manually generate the .hidden
directive in the assembler output. This is not perfect: it is hard to
use for C++ functions and methods (manual mangling of the name is
needed), and inline assembler can only be inserted inside functions. But
the alternative is patching gcc2 to add support for the function
attribute, and I don't want to dig into that today.
- Show view names in addition to class names
- Use class_name from ClassInfo.h to get class names (no functional change)
- Use 4 spaces for indentation instead of 2
This is an old version of libc++ that was imported in an early attempt
of building Haiku with clang. It is currently not used for anything. In
fact there never was a Jamfile to build it.
* Works a bit better with dark themes
* Has some interesting alternative design elements
* MIT licensed
Change-Id: I6cfd1d4d05016fb014d515d94cff3b8c8d0298b2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4508
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* PCI ID's from Linux
* There are a bunch of NAVI quirks around 3d rendering pipelines
but not many around modesetting (which is the only thing we care
about)
Change-Id: If63e31fe1d37d9d95f2a71c222a4cda7a2914a5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4467
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Add lots of comments explaining things in the code. Also fix parsing
of Beta updates which have hrev version numbers with an extra bit at
the end, like hrev12345_67. Include architecture in the GRUB menu
title, so you can tell 32 bit and 64 bit installs apart. Switch
back to #!/usr/bin/sh, like all the other probes do.
Change-Id: Id47afe5029369c739d5177b1dd917c7d1d631ad6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4498
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I9c660b1569b5439f2cd9088fde4e96512e7817d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4496
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Original version of 83haiku as seen in Debian Linux, for detecting
pre-package based Haiku OS and automatically setting up a GRUB
boot menu item for bootable Haiku partitions.
Change-Id: I0d1fe4c9b395e7912b2398ab6bac5c25d92aa64a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4495
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
tested with success at least on VGA, see #16069. Thanks TmTFx and rudolfc!
Change-Id: I4183416b09216b111984658eb8b23c8f62a0e36d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2762
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Only one code change: for some reason, GCC chokes on the cr3 functions
as macros (throwing errors about invalid registers.) The BSDs have them
as inline functions instead, so they are converted to that here.
Tested and working. There seems to be about a 10% decrease in CPU time
on some compilation benchmarks that I briefly tried.
Change-Id: I31666297394d7619f83fca6ff5f933ddd6f07420
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4515
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On x86_64, the KERNEL_ARCH should really be "x86_64", but it was "x86"
as the architecture sources/headers directory is shared between 32 and 64 bit.
Should not be a functional change on any platform outside x86_64.
Size of gBootGDT[] is 'USER_DATA_SEGMENT + 1' defined at line 26,
and it equals USER_CODE_SEGMENT, so gBootGDT[USER_CODE_SEGMENT]
is out of bounds at line 44.
Change-Id: I1374f4d1185b6a47f910ac128d49a07cdd80d925
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4536
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Some are still in-tree and need to be removed, but this takes care
of all recent Intel, Realtek, and also the old Ralink chips.
This cuts down the size of haiku.hpkg by close to 10MB.
This reverts commit 6683314327.
Apparently, on closer inspection, this is not actually correct:
TARGET_KERNEL_ARCH is "x86" even on gcc2, and not an index into
the TARGET_CC_* etc. variable sets. That is pretty confusing and should
probably be fixed.
The static asserts are broken on GCC2 and so did not catch this. It appears
nobody has ever tried to use this structure on 32-bit plaforms in the upstream
libraries or SPDK/DPDK?
Fixes #15212.
They are not in any way architecture-specific. Simplifies the various driver Jamfiles.
This also paves the way for some upcoming changes that make the kernel always be built
with the non-legacy GCC...
We will pick up events that have no match later on, and if we return
an error here, it will prevent the job from being initialized, which
we definitely do not want.
Fixes #17291.
Translators and media-plugins are the main source of dependencies in haiku.hpkg,
and thus the main source of packages being pulled into chroots, especially
HaikuPorter chroots. (FFmpeg pulls in a rather large array of sub-
dependencies, itself.) So, here we break all the translators into their
own sub-package.
For now, haiku.hpkg is declared to depend on haiku_datatranslators,
so that users will not suddenly update and have no translators.
In the future, this will be dropped.
Note that this is only done for the primary arch at present.
Secondary architecture translators remain in the main secondary package
for now.
Change-Id: Id0b352f34f7110b79ec7787792bf3ae0edab4054
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4477
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Part of #9460
Change-Id: Ibcc30af0c2d351742cbedd6df15b2880b92edfee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4513
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Rename TRACE to INFO as it is always enabled.
* Rename TRACE_EXT to TRACE in line with other drivers.
* Move most previously-TRACE-now-INFO message to TRACE,
removing them from debug output.
This should get rid of the Highpoint-IDE syslog spam in every boot log.
We want to continue iterating until we have either reached the end
of the vectors or until we know that length is greater than MAX_FRAGMENT_SIZE,
so we need <= here, not <.
Fixes a problem that can arise with the
selection of language when adding or
editing user ratings.
Fixes #11316
Change-Id: I85625cdc156458d88f4d1ca01ae889d954364ffd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4511
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the external event is sticky and already triggered, then we want
to trigger any newly-added events immediately. This fixes "boot hangs
on rocket" regressions following 4f126f690c,
which seems to have exacerbated this already-existing race condition.
Fixes #17289.
Change-Id: Ie405826cc50255895c8831c34b8bdf902e584eb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4510
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Refactor ResolveExternalEvent to actually return the resolved event,
not just whether or not one was found, and then skip resolution
in TriggerExternalEvent and ResetStickyExternalEvent, which now
should only be passed ExternalEvents.
* ExternalEventSources now store destination Events, not Jobs,
following on that refactor.
* The second variant of ResolveExternalEvents is dropped,
and instead the Register/Unregister functions are implemented.
* Trigger and ResetSticky are now done in ExternalEventSource,
which now keeps track of whether it has been sticky-triggered
or not, though it does not use this information yet.
These changes should not affect behavior, they largely constitute
a reorganization (though some TODOs are resolved.)
Change-Id: I46a51cac0edb90e90b154ef9c94791cb7a1aad94
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4509
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is similar to with the registrar and debug_server,
both of which are started before app_server, already do.
In the case where we cannot connect to app_server for
_SuggestMountFlags, we default to read-only.
(This should however never happen, at present.)
axeld did all the hard work in 4bf862e368
but did not actually change the instantiation to use BServer. We now
do that, and pass "false" for "initGUI" to avoid connecting to app_server,
as syslog_daemon never does anything GUI related.
Only one #ifdef, the rest is all in basic if-tests. Relatively minimal changes,
and now the virtual keyboard device gets all the improvements made to the keyboard
layout view over the last 6 years.
The drivers do not support this properly at present, they would
run the other transfers interspersed with fragments from the fragemented one,
which is obviously the wrong thing to do.
No USB device drivers seem to do this at present (it would cause data
corruption if they had.)
Fixes #17275.
These come from the Haiku Newsletter, issue 56 article 2, which I
managed to retrieve the source from the Wayback Machine. (They
are based on applications from Be's Sample Code distributions.)
Jamfiles not yet included; the source is in unmodified form,
except the RSRCs have been decompiled to RDEFs.
these colorspaces are packed as RGB or RGBA, not BGR or BGRA.
RGB48_BIG and RGBA64 only differ in the endianess of the channel the 2-byte value.
this is a big difference with RGB24_BIG and RGBA32_BIG, in which case _BIG
means the order is RGB (BGR) and not BGR (BGRA).
BGR48, BGRA64 could indeed be added, if needed.
I chose 0x11 and 0x12 arbitrarily, but given the order of channels 0x1011
and 0x1012 might make more sense. This would mean using another bit for "real"
bigendian colorspaces.
Only the color conversion to 32-bits is implemented.
Tested with the RAWTranslator modified to output 16bpp with success.
Found some references in enum AVPixelFormat in libavutil/pixfmt.h.
Change-Id: I4b023dec85d01f1e63e1b053139e5bb5d263a0e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4468
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Without this, kernel will crash on boot when a framebuffer
isn't provided by bootloader. (like on the riscv64 today)
Change-Id: I5ec64db30972c7c3b19e4cdb31f0fe72b5982c0f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4494
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I44211b3533f99338d7246e88593fc8838628904c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4485
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* For riscv64,arm,etc, the controller init is used to
parse the fdt to detect the PCI controller.
* Without the controller being init'ed, we don't yet know
the base registers of the PCI controller for io activity
on a lot of architectures / platforms
* x86 doesn't seem to use the io regs until well after
controller init
Change-Id: I2a04e30e4dc675657b5cd9183240dafd35473998
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4484
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Refactored version of X512's original work to split out
the ecam and fu740 PCI Controllers
Change-Id: I631885af03b0118fb0084ed7aa4a5aa0a355b0fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4435
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This fix is for ticket #9460 to potentially enable -Werror for JPEG2000Translator.
Original warning: 'char* strncpy(char*, const char*, size_t)' specified bound equals destination size [-Wstringop-truncation]
- Replaced several occurrences of same string with existing constant.
- Use strcmp instead of strncmp as one string is guaranteed to be null-terminated
- Replace strncpy use with strlcpy as seen in other code places.
Change-Id: I5e7ed0de10dc40447a64fe77a7909af577e128ac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4472
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The pre-allocate functionality was added to Haiku in hrev54704. It needs
support at the file system level though, and it is yet to be implemented by
BFS. Some applications (and glibc!) implement a fallback mechanism using
ftruncate(), including the LLVM tools, but they go to this fallback
mechanism when it is clear that the operation is not supported. In particular
they look for EOPNOTSUPP.
The current implementation returns B_UNSUPPORTED from the vfs layer when a
file system does not implement the feature. This error code this not map to
a POSIX error. This change converts it to EOPNOTSUPP.
Change-Id: Ief382b0f4d462dfedf84c731f68f69731de4498c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4492
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Now that we are not setting fFragmented in VectorLength(), we can
reset it in SetVector based purely on the length of the newly set vectors.
We also need to set it in SetData, as SetVector does not call this.
This fixes an oversight in bc7fd43358.
In a few instances, we need to not wait for objects to become unbusy
during ID puts because we expect they still will be, e.g. in the case
of Control pipes with submitted transfers that are still running. There,
we need to put the ID, cancel transfers, and only then wait for the
object to become unbusy.
Technically, this is a functional change, but at least in practice
it will have little real-world effect, for two reasons:
1. The DefaultPipe's Busy flag is basically never updated (the Device's
busy flag is generally used instead), so it will virtually never be
"busy".
2. Most devices have no Control endpoints besides that default one.
Change-Id: I32ff4094effeac9ec74546c9643ea2025418e1c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4491
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way, any endpoints or interfaces which are currently using the
default pipe for SetFeature/.../etc. will return immediately and
become unbusy.
Should fix the remaining KDLs in #16794 and #16969.
Change-Id: I6615fc03394a0c50eae1ca7da2fb43f243841613
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4490
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This mostly only matters for the Device DefaultPipe, which is still
accesible even after its USBID has been put, but it makes sense to
do this in general, too.
Change-Id: I6711f1ce8fe79dff54927e3b5e60dec15bb58b14
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4489
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Control pipes have internal structures to wait for queued requests.
When force-cancelling queued transfers, the callbacks will not be called,
and so such transfers would be left hanging until the timeout occurred
or the destructor destroys the semaphore and mutex.
This probably will not fix any hang-related tickets, though, as force
cancellation is pretty much only used during device/pipe teardown.
Change-Id: I41db7caf380cdd082bc3509e95262317489bf100
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4488
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I was not actually aware that our USB stack already supported
breaking (bulk) transfers up into smaller units as necessary;
these APIs are not very well documented.
This makes #15569 occur far less often, though it is still
more than possible to trigger.
It did not return the length of the vectors, but only the current
fragment's worth of vectors. It also modified the fFragmented flag,
which really should have been set in SetVectors in the first place.
As everything seemed to call IsFragmented after VectorLength,
this is not a behavioral change.
This allows us to stop storing the package flags, which saves 4
bytes per package node (a value that really adds up when there
are thousands upon thousands of PackageNodes), at the cost of an extra
sizeof(int32) allocation for the WeakPointer object per-package (of
which there are are much fewer, of course.)
This also is safer overall, as now consumers of GetPackage() or VFSInit()
will now hit a NULL dereference if they have failed to check if the
package still exists, instead of a use-after-free.
Change-Id: Iea97ffcd491c6e2da7093730a7fa951b84dcefdf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4478
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This is both more correct, as we need to not read past the 'size'
position of the passed pointer, and much faster, in the case where
the passed pointer is into some very large block of memory.
This provides an unbelievable speedup to a microbenchmark posted on IRC
that makes heavy use of this function in tandem with some rather
large allocations. (Some variants of it go from multiple minutes
to under a second!)
It has been since 2019. It seems to be added to images anyway,
probably because something else depends on it, but for correctness,
it belongs outside the REGULAR section.
If the debug_output pointer is just a kernel_args_malloc'd structure,
then it is already mapped and we should not be re-mapping it; we only
need to do that if we are using a fixed-map ring.
Eventually, EFI should get support for the debug log ring_buffer
like bios_ia32 has for transparent handoffs, but this preserves
everything except for the pre-start MMU dump, which is an improvement.
Fixes #15455.
It was removed in hrev55422 as we never had declared it in any headers.
But it seems some software came to depend on it anyway. Reinstate it,
and add a declaration for it, behind _GNU_SOURCE.
This reverts and replaces hrev53141, hrev53200~1, and hrev53888.
Two years ago (in hrev53141), I added checks to validate that Devices
were not in the process of being torn down before using them, to fix
a race condition KDL. Further logic was added in hrev53200~1 and in
hrev53888 for Pipes.
Well, upon closer inspection following the reports of #16794 et al.,
it appears upon closer inspection there were still two more race
conditions lurking in there: the first between Get and InitCheck, and
the second between InitCheck and use.
To resolve both of these, a new atomic "busy" flag is added to objects,
which is incremented before unlocking the objects array, and then
waited on before actually proceeding with teardown.
The older checks about initialization status are now superfluous
and are removed in favor of an earlier PutUSBID() invocation in Device.
While #16794 was fixed by hrev55429, some of those or related KDLs
might have been caused by these races. This also re-resolves #15115,
along with #14949 and #15710.
Change-Id: Ifcae84945a81123af5ef4683a6e33dc1eec5b23c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4421
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This array was introduced by korli in hrev44089~1 (2012). It "mapped"
ports to slots using a device's HubPort, and then used this value in
FreeDevice() to locate the xhci_device struct in question.
Well, when there are non-root hubs in use, the HubPort values can
of course collide, leading us to tear down the wrong device in many
circumstances. This appears to have been the true cause of #16794,
and probably also #16878 and #17266, and maybe even some others.
In case any one message (or, more likely, importing the bootloader's
syslog buffer) is too large for our buffer, do not discard it, but
keep as much as we can, and print <TRUNC> at the beginning of it,
to distinguish from <DROP>. (Documentation already notes <TRUNC> as
a possible thing to find in the syslog.)
If keep_debug_output_buffer is true, then we reused the syslog buffer
the bootloader allocated (and which has just been re-mapped above),
so we do not need to write the buffer in again (and moreover doing so
is incorrect, as it contains a raw ring_buffer header, and will be
larger than the buffer.)
This fixes "<DROP>" appearing at the beginning of all syslogs (or at least,
ones that began with handoffs from the bootloader) spuriously when
the whole buffer was really present anyway.
* Destroy interfaces and endpoints before deleting the default pipe,
as all of these may actually use the default pipe at any time
while they are alive.
* Remove the default pipe and then ourselves from the stack before
deleting the default pipe, as it also may be used at any time.
May help with some of the open tickets about USB stack KDLs.
This fix is for ticket #9460 to enable -Werror for ext2.
- Unused functions are removed.
- The ASSERT macro was redefining a different ASSERT macro from the included files. Now it gets undefined first.
- One comparison side was cast to ptrdiff_t because X86_gcc2 complained about signed/unsigned comparison
Change-Id: Ib0caade2f83de34c04acc0fc6aa5ed50712daec4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4453
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Instead their IDs are indexes into the stack, and are used primarily
for TRACE*() printing, so move the getter function into a "protected"
block and rename the variable appropriately.
AllocateAddress() is the pre-USB3 way of doing things;
as we never use it anywhere else and it is specific to
each BusManager, we always just got 1, which is what
the root hub will always be anyway.
Additionally, clarify the logic in _InsertEndpointForPipe
that is special-casing the root hub.
No functional change intended.
glibc's hsearch and tree functions are old and rather slow.
While these APIs do not appear to be used very often, these
changes can make a big difference: in one benchmark I was sent,
this change is nearly a 10x speedup or more in some cases.
This is a source compatibility break from BeOS, but should not
be an ABI one (I checked, the symbols are identical.)
Also use "= {}" in the definitions of the fields. We use this
in plenty of places in the kernel, so it should be OK for GCC2.
Change-Id: Ibe05b2236d46024d7b4563ae16e1cc7140fed965
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4434
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Modifications made on hrev55413 removed UsageID from array Items,
but also (bug here) broke UsagePage, needed by KeyboardHandler
in order to recognize items as Keyboard ones.
Fixes #17263.
Change-Id: I4b73c69240f31d3c8c2aacf6bab0d270f2053387
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4458
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Follow-up for Alan Shearer's change. Useful when the buffer contains the
character "%".
Change-Id: Ia6771a2d71306ca97e7c03f0e986ad3cfe100684
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4459
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
the file position corresponds to the end of the buffer.
Change-Id: Ib67dcfe1f43d959777c2f6dbf84181f25a022a7c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4447
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* I've added support to multiple min-max ranges to array reports too.
* All possible usages are stored in an array (Vector<uint32>). Perhaps, this can be squashed into an array of ranges.
* Usage array is stored in HIDReport class, so there is only one copy of it.
* HIDReportItem no longer has UsageMinimum()/UsageMaximum() as this no longer works. Instead, a Usage() member has been introduces.
* HIDReportItems of type variable, have a Usage ID assigned to them. HIDReportItems of type array have a zero usage ID as it has no sense.
* Having a variable typed HIDReportItem to store a range of usages ID doesn't seem a good idea to me because Data() method would have to return the values of all usages... or perhaps ask for a specific usage value with something like Data(0x03). This will require changes in hid stack and overcomplicate things.
* A bitmap keyboard is a worst-case scenario: Near a hundred of usages (uint32) are stored and the same quantity of HIDReportItems are created (this is already happening on Haiku). It doesn't seem a resource drama to me.
* Keyboard Handler has room for improvement, but I would like to left that for another patch series.
Change-Id: I556fa0aebfda831ef5334be5ae3a37f099ffa35d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4403
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This helps with creating a sysroot, otherwise extracted package
links refer to /system, which is outside of the sysroot.
* Should have no functional impact on Haiku, as these are already
symlinks
Change-Id: I29f719dc2c0839dd090e7f33eea0b8f98e0d6355
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4218
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Some applications may request per-page protections for an especially
large area (e.g. multiple GB), which leads to allocating a rather
large page protections area (e.g. 512KB), which we cannot allocate
without locking the kernel space to get new slabs.
We only need to avoid locking the kernel space if the area in question
is in the kernel space, as in that case, kernel space will already be
read-locked by the current thread.
Fixes #16898.
Change-Id: If52413a594da66edfc2821811d959085a2c3c78e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4436
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This codepath is only hit for especially large malloc'd areas that
do not fit into an object cache, which is a rather rare case to
have in tandem with DONT_LOCK_KERNEL_SPACE, but we need to be
prepared for it in this code anyways.
Probably this codepath would previously have caused a hang due to
attempted double lock of the kernel addres space. Unfortunately
it appears our rw_locks do not actually detect that at present,
so likely I should investigate that next...
Change-Id: I3c9059d3e3939271beeeff221ebc921bc07ddf00
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4438
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This removes the use of the destructor in the move assignment operator, as it
may rely on undefined behaviour from the compiler. Additionally, some duplicate
logic to dereference and free a shared string has been unified under
_ReleasePrivateData().
Change-Id: Ie9f51d598c734f83cd0fba49b651315c6e9c8aac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Video generated by DemoVideoProducer is now displayed correctly
Change-Id: Idaed170a355ae7ed0b50c143a5c6c33da1393551
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4401
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Most of the ClonedNode methods just forward calls as appropriate to
fNode or fClonedNode, but missed that fNode is itself always an ObjectNode.
Now we store that, and forward on the two relevant ObjectNode calls.
This fixes kernel stack trace function demangling where the symbols
contained clones (e.g. "[clone .localalias]", etc.). Before this commit,
such symbols would just appear as "()" and no more.
The "[clone...]" block will in such cases appear after the function name
and not after all the function parameters, as the two are returned
separately and there is no way to indicate how they should be printed
in the kernel's API usage of these functions.
ClonedNode was only introduced a few months ago in hrev55147,
so this has not been broken for too long.
This file just uses fprintf(stderr, ). Probably it should be
converted to use macros...
This allows for easy debugging of silence by restarting the media addon
server in a terminal. Eventually we should fix #17245.
Only on non-GCC2 for now, as GCC2 does not have -fvisibility.
An opt-out is left as a possibility, and is unfortunately necessary
for libshared and libicon, as these two are used even in WebKit instead
of linking to the .a. However, libcolumnlistview, libagg, and a whole
bunch of others are now no longer exported, so this is already a major
improvement on what symbols we were leaking.
This may provide performance differences for consumers of these APIs,
as GCC and the linker are now free to merge and directly use functions
that previously could have been semantically interposed. AGG usage in
app_server, especially, may benefit.
We can also now remove the addition from libnetservices, so do that.
That is, it will now pull in NEEDLIBS and LINKLIBS set by LinkAgainst
from static libraries also built by Jam. This allows specifying what
libraries other static libraries need only once (in most cases;
occasionally things are not evaluated in a sane order and then
this does not quite work.)
Use this for libnetservices.a, which needs libshared.a, so that
dependencies on it do not have to be declared within most in-tree
consumers of libnetservices (e.g. Package Kit, http_streamer, etc.)
This implements the "rule of 5" for this type. While the copy operation for
BString was already using shallow copies of the underlying data, this change
further optimizes moving the data from one object to another.
While it is not the intention to implement move semantics to all types in the
legacy Haiku/Be kits, data types like BString are good candidates, because move
operations are often useful when working with data within an application.
In this implementation, the internal data of the string object will be set to
NULL, thus leaving an empty string.
Change-Id: I16bf9424f9b17f622b0b57659b80628e18760288
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4428
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Otherwise, the symbols will be re-exported into whatever shared
libraries the static library is linked into, and potentially conflict
with other applications that also linked against some other version
of the same library and symbols.
Fixes #17134, or at least the crash portion. I couldn't get any
audio or video to play here, they seemed to just cause WebKit to
stutter and hang a lot when trying to load pages with them. Maybe
that's expected behavior, though?
We are no longer running these addons on BeOS.
Change-Id: I4baa562bfdfaab56a92689c29d068ec59b2ee9d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4433
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If the incoming node is still pretty generic, we have to specialize
the input format to the output format in order to not be left with
wildcards.
Additionally, ensure that the frame sizes match up. MultiAudioNode
silently rejects buffers that are not sized precisely as it wants
them, so we need to attempt to have equivalent frame counts
on either end.
* We are no longer on BeOS and can now use format_is_compatible
and format->SpecializeTo.
* Remove set-but-unused media_format in node_output.
This allows AudioAdapter to connect to MultiAudioNodes.
However, no sound is produced. I have yet to determine why.
In the meantime, this seems to at least not break audio.
Change-Id: I983a496556c52a4ccde0c2cd165c659d597b84c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4432
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Apparently BeOS' SpecializeTo() was broken, and so when this code
was introduced in 2003, it came with its own copies of the
specialization routines.
We don't run on BeOS anymore, and our specialization routines
appear to be identical to these, so, we can drop them.
Should not result in any functional change.
This path normalization was functionally a recursive lstat(), which
should theoretically be identical to rooting the path in the CWD
and then normalizing the rest of the components after that.
Well, a recursive lstat() is much slower than simple manipulation.
How much slower? Well, on my system, the existing lstat() version
took up a combined total of 63,284,607 us for building haiku.hpkg
(only the package itself, no other components rebuilt), while
this new version uses just 47,901 us -- and this just for a @minimum!
I performed a full @nightly build with both versions in use at once,
with an abort() in place if paths ever did not match, and it
did not fire once. (I even sabotaged the new function just to
ensure that it would actually find differing paths.)
This code was merged in 338b8dc301 (2005),
and has remained largely unchanged since then. I don't know what the
rationale was at the time for using this method instead of this much
simpler version. Perhaps the 3-argument normalize_dir_path was written
first and used more, while this 2-argument version was added later
as a simple shim? But the original commit has no uses of the 3-argument
version aside from the 2-argument one...
Either way, this is an absolutely unbelievable speedup to Haiku builds.
These functions are hit in every I/O operation of all libroot_build
users, and their usages really do add up, as the example above shows.
Fixes #16288.
Change-Id: Ia11f64b0d4106ee62f22741a32ccc0c75c184442
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4427
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
It seems GCC has the same behavior as Clang now, so we can ignore
errors generated while preprocessing. (Previously we did anyway,
before the recent commit adding -e to JAMSHELL flags, so this
just continues previous behavior.)
* Drop ArchUART8260 layer to reduce complexity. It's whole
existance in life was to adjust the mmio alignment.
* Fold architecture mmio alignment into DebugUart
* We could potentially pass a Init(int mmioAlignment)
arg in the future if the macros get too messy.
* Move Barrier code back a layer into DebugUART
* Fixes the arm uart and EFI build
Change-Id: I0f127d902993e9f6e6a03cac8c7c37c0363134bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4422
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>
We have a number of "actions" blocks in our Jam rules with more than
one command, and so without -e, the actions will only fail if the last
command does. This is clearly not what was intended in virtually all
cases, so we should pass -e to the shell to ensure any command failing
causes the whole actions to fail.
I am kind of surprised that nobody noticed this before now, even
in the original Jamrules going back to the Perforce days. I only
noticed it because I experimented with making "rm" fail to find
places where it was invoked instead of $(RM)...
Change-Id: Id83a1aeb9736be1d08ba10bb52ab81f2cab11625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4426
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Some logs are emitted even when nothing at all is happening, constantly
spamming the syslog. Log them only the first time they happen.
Change-Id: I81511a7ce245c2141fa3dcd141b2f3732d9b51ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4424
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
In some cases, we don't need the full tracking of every byte received at
the PS2 level, but higher level traces from specific devices will be
enough.
Change-Id: I31984e6b7784b5d033b457f43f3793f772213f4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4423
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Get rid of fPacketSize and use fSamplesCount in GetBuffers instead.
* Clarify logic in _TransferCallback.
* Properly multiply in kSamplesBufferCount to fAreaSize
(this should be the only functional change in here.)
The larger buffers (now similarly sized to HDA at least in the
default cases of 44100 or 48000) seem to help with jittering
and discontinuities, which are significantly reduced now,
at least under emulation.
In hrev55048, checks were added to bail on initialization if invalid
audio formats were present either in inputs or outputs, which broke
any audio nodes that supported only one or the other. Now, instead,
we check channels first, and even then do not bail on invalid formats,
but simply do not declare support for inputs or outputs respectively.
This solves the initial cause of #17235. However, that ticket refers to
an unrelated problem this bug merely exposed, and so it should remain
open until that is resolved.
Stalls cause "HALTED" conditions on endpoints, so use B_DEV_STALLED.
Also clarify the comment referencing the specification, and add a
missing linebreak to the error message.
* Allocate the descriptors array separately from the data area.
* Clone the data area for kernel use separately from userland use.
Fixes the remaining SMAP problems with this driver.
An "Input" terminal in USB audio terms refers to any stream of audio
going "in" to the USB device, whether that be from the outside world
(e.g. a line in jack) or from the computer (e.g. via USB OUT endpoints.)
So we cannot rely on the terminal type to tell us whether it is an in
or an out for our purposes, we have to check the stream type, and then
use that to declare to multi_audio what kind of stream we have.
Fixes USB audio mixing up inputs and outputs, especially on devices
that only have one or the other and not both. (QEMU manifested
this problem.)
This may help fixing lgtm build failure "There is not enough space on the disk".
Change-Id: I5db5748b73e611ec6b66a8effdf5ad39969f9bde
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4415
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The USB Kit uses it, so this allows the USB Kit to stop including
USB3.h.
Change-Id: Ifde025ec41bef92013fda0440d60b7216cfdbe4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4413
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It seems this has been broken since I originally wrote it in 2019,
but it only gets called in two scenarios: on device unplug (where
it does not really matter), and on interface changes (where it does.)
Apparently very few people tried to use devices that depend on interface
changes, because those would have been totally broken by this.
There were actually two bugs here:
1. ConfigureEndpoint should not be called with the Deconfigure bit set.
(See inline comment.)
2. The first bit must be set in the context add flags.
Fixes #14971 at least, and possibly others as well.
...to usb_endpoint_superspeed_companion_descriptor, as it is
really SuperSpeed-specific (there are more companion descriptors
introduced in SuperSpeedPlus.)
No functional change, and this is a private struct at present.
* We really should get out of the habbit of making up
our own architecture defines.
* __riscv with an additional __riscv_xlen is the
standard that developed... let's just roll with it.
Change-Id: Ieb777d48340ae25a6d66f66133afa0ec5c6da9b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4402
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Including thread.h brings a massive array of things with it from
the kernel thread arch headers, team and thread definitions,
hash tables, linked lists, Referenceable, etc. that the vast majority
of AutoLock.h consumers neither want nor need.
So, put these in a separate header, and adjust all consumers of these
lockers to include the new file.
This change exposes the fact that a lot of files were inadvertently
making use of headers included indirectly through thread.h. Those
will be fixed in the next commit.
* Set driver module name of device_node.
* Set device module name and path for published devices.
This helps to understand what driver is used, and it's /dev path in the
Devices app.
Change-Id: Ibd902a322da7e4276052bd4429a7b869a56a592b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3390
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Previously these were just using the raw function name, which led
to markers like "Slab_begin". Now we prefix RANGE_MARKER_ so there
is absolutely no chance of confusion, and the symbols are clearly
visible in dumps.
Also add a note that the kernel must be built with -fno-toplevel-reorder
for these to work. (It seems when this was implemented, GCC had not yet
implemented top-level reordering.)
They are only used for debugging with the tracing system in a handful
of places, and -ftoplevel-reorder is enabled with optimizations for
a reason, so it makes more sense just to note this and not to enable
that option by default (i.e. in the off chance someone will want to
use these in non-debug builds, like I did.)
Will allow USB3, 64vCPU, NVME, etc. Versions below 13 are only for vmware products currently EOL.
Change-Id: I83303ab985f615852267e2539b350f72f05231e7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4410
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unfortunately it does not work, I get this when invoking
allocations_per_caller at the kdebug prompt:
92513 9162096 0x0000000000000000 <NULL> + 0x0 (commpage) (nearest)
12602 2108408 0xffffffff80132a50 _Z23add_alloc_tracing_entryP11ObjectCachejPv + 0x70 (kernel_x86_64)
The stack tracing system must be broken, or maybe it has never been
properly adjusted for x86_64.
If the timeout is already >= B_INFINITE_TIMEOUT, we do not need
to do any of the following math (which would usually overflow anyway)
and can leave the timeout alone.
Spotted by kernel undefined behavior sanitizer.
For the kernel team, we now assign it in team_init instead of having
a special case in Team::Team(), making things more similar to the
userland team creation.
Should not change any real functionality as Team::Create calls
almost nothing outside of this file.
This translator only supports still images for now, and supports both
decoding and encoding.
Encoding support has been tested only with aom, rav1e doesn’t build on
Haiku yet, see https://github.com/haikuports/haikuports/pull/5534 for
one of the missing dependencies.
Change-Id: I716f4b862ed316b89b227bfed38072d72074201f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3040
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The "update dependency versions" step automatically adds the requisite
versions to this file during the build based on whatever the build
system is actually using, so this is not necessary; and it seems
that some architectures besides GCC2 are still on a version of ICU
less than 66.
... so that you can see the extension.
Change-Id: I0c3cdcede912f6ccc7dfb8360bfd82599c8117c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4323
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We do not actually need a SetupFeatureObjcetsDir here, as this build feature
is used unconditionally if it is available (unlike OpenSSL which is not,
and which needs a feature objects directory.) It appears FeatureObjectsDir
expects to be called unconditionally, i.e. in an "else" as well as "if",
so this actually caused some build oddities.
Additionally, since it is built unconditionally if available, we have
to put it outside the "regular" checks in the PackageInfo so that it
will be included in the images. This fixes booting @minimum images,
which was apparently broken at some point when "zstd" was inadvertently
removed.
* Merge all except the x86_gcc2 one into a single "generic" one.
It is now exactly the same on all architectures, save a single
ifdef for x86_64, which needs a different compat version, as there
are still some packages built that far back and never rebuilt since!
* Group the requires according to category: first any arch packages,
then commands, then the GCC syslibs, then packages always depended
upon if they are available, and finally packages only depended upon
in "regular" builds.
* Put all packages inside HAIKU_BUILD_FEATURE_* ifdef tests,
and order them alphabetically within their category.
If I have done this all correctly, at least x86_64 should get an
identically generated haiku .PackageInfo as before this commit, save
the reordering changes. Others may differ based on package availability,
as they were missing the requisite #ifdef sections.
This is a BeOS app compatibility fix.
The comment in SetBits implementation said that B_RGB32 imports only
24 bits of the data, but that doesn't seem to be correct.
Fixes #12931
Change-Id: I826a7e358ea379b8bf1550c899e82b623e5c21b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4319
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
An effort was started some time ago to consolidate all internal
documentation in the git tree. However, this was just an accumulation of
files in various formats without any strucutre or way to browse it,
which results in no one even knowing that we have docs here.
This converts most of the files to restructuredtext and uses Sphinx to
generate an HTML browsable user manual (with a table of content and a
first attempt to put things in a global hierarchy).
There are almost no changes to the documentation content in this commit
(some obviously obsolete things were removed). The plan is to get the
toolchain up and running to make these docs easily available, and only
then see about improving the content. We can migrate some things off the
wiki and website, and rework the table of contents to have some more
hierarchy levels because currently it's a bit messy.
Change-Id: I924ac9dc6e753887ab56f18a09bdb0a1e1793bfd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4370
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Define thumbnail attributes in Attributes.h:
Media:Thumbnail to store the thumbnail,
Media:Thumbnail:CreationTime to see if thumbs need to be regenerated.
Store 128x128 thumbnail in attribute, for icon sizes smaller than
128x128 down-scale the 128x128 thumbnail. Use B_FILTER_BITMAP_BILINEAR
to down-scale the image using the bilinear scaling algorithm which
creates nicer looking thumbnails than the default scaling algorithm.
Store thumbnails as WebP images which compress smaller than PNGs and
fit in the inode better at 128x128.
Check the file's modification time in GetFileIconFromAttr() and compare
it to the thumbnail creation time. If the file has not been modified
since the last time we generated thumbnails return the thumbnail from
the attribute, otherwise fetch a new thumbnail with GetThumbnailIcon().
Add "Generate image thumbnails" Tracker setting. Default is turned off
for now. To generate image thumbnails you must first turn this setting
on in Tracker Windows preferences.
Spawn a get_thumbnail() thread to generate thumbnails and retrieve them
later on from the window thread to fill out into the icon. This should
improve responsiveness of generating thumbnails from a folder with a
lot of images. The generator thread will write the thumbnail data to an
attribute if on writable BFS volume.
If not on writable BFS volume, the generator thread will send the data
back to the original thread through a port by calling write_port().
When the thread is finished creating the thumbnail it sends a message
back to the Tracker application thread to update the pose which
instructs the window thread to look for an thumbnail. It either finds a
thumbnail in an attribute, or picks up the thumbnail data that has been
sent through write_port() using read_port().
This works on both read-write and read-only BFS volumes but it still
depends on the presence of a BEOS:TYPE parameter to have been written
to the volume before it became read-only. Thumbnail generation does not
work on other read-only volumes for example an ISO-9660 CD, but it does
work on read-only BFS volumes for example the BeOS R5 CD.
Move BPrivate::CheckNodeIconHintPrivate() from BNodeInfo to Tracker
Model CheckNodeIconHint(). Create Model::CheckAppIconHint() and look
for a vector icon or mini and large icon in that method. Check that
the base type is directory, volume, trash, desktop, or if executable
call CheckAppIconHint().
Add 1 to temp_name to fix the following warning:
src/kits/tracker/FSUtils.cpp:2437:12: note: 'snprintf' output 3 or more
bytes (assuming 267) into a destination of size 266
Rename temp_name to tempName following our style guidelines. Use
strlcpy() and strlcat() instead of strcpy() to safely copy the string.
This fixes thumbnail generation on 64-bit Haiku.
Change-Id: I7f927a5a1f8cf65e4b1aa1e0eb55bbfae87fd969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3163
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It's not allowed to enable the screen before having set a mode. At least
in the case of the intel_extreme driver, this creates some problem. Move
the call just a bit later in the init process, where the mode is already
set.
Change-Id: Iaa665f0edc15316890032f1a5928f33634dc8749
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4362
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: François Revol <revol@free.fr>
Reviewed-by: <BeagleJoe13@gmail.com>
The window is not easily accessible from the application itself, so this
change is practically not that useful, but it's still a good idea to continue
replacing old BAlert windows with BAboutWindow in order for the Haiku source
code to be exemplary as far as developing applications is concerned.
Change-Id: I05ea971ed0f8a996d5e168066b18eb7fe8bd5b3e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4331
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
team.cpp address_space change is needed in
arch_thread_init_kthread_stack to set initial thread page
translation map. It also allows to simplify some debugger code.
DEBUG_PAGE_ACCESS check is currently incorrectly implemented in
RISCV64VMTranslationMap and disabled to avoid panic.
gHtifRegs = 0 change is needed to avoid using HTIF when it is not
available. gHtifRegs != NULL check is used to detect that HTIF is
present. 0x40008000 is TinyEMU HTIF address. HTIF is emulator specific
device that provide serial IO and shutdown capability (and maybe
something else depending on virtual machine).
Change-Id: Ic4d567b28c49799ae0f55223dd983a752823bab4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4328
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Use generic c versions of memset and memcpy
Wwrite fast asm for that later, therefore no need for arch_string.S
* Disable FDT and DTB until ARM64 is ready
(WIP: do it later)
* use ELF64
* Use generic c versions of memset and memcpy
Wwrite fast asm for that later, therefore no need for arch_string.S
* Disable FDT and DTB until ARM64 is ready
(WIP: do it later)
* use ELF64
* virtio_mmio for riscv64,arm,arm64
* enable new FDT bus for riscv64,arm,arm64
Change-Id: I5141de4e0bfcb44c5368dfafdf68ebf06ca5fb93
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4063
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* This models the CpuInfo into a cross-architecture
platform_cpu_info
* Originally I was looking at merging this with "arch_cpu_info"
however that is "overall cpu" while CpuInfo is "indivial core
information" packed into an array.
* Since every dtb platform will report individual cores in fdt,
having a common cpu core info struct with at minimum the core
id makes sense.
* This could likely be refined further to some kind of core info
packed inside of arch_cpu_info, but this will fix arm,arm64,etc
for now until someone wants to dive into that.
Change-Id: Ia18a352403cd0da7130c1e637fc205d4311478ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4363
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
alc(4): add support for Mikrotik 10/25G NIC
The new Mikrotik 10/25G NIC is mostly compatible with AR8151 hardware,
with few exceptions:
* card supports only 32bit DMA operations
* card does not support write-one-to-clear semantics for interrupt status
register
* MDIO operations can take longer to complete
This patch adds support for Mikrotik 10/25G NIC to the alc driver
while maintaining support for all earlier HW.
The patch was tested with FreeBSD main branch as of commit
f4b38c360e63a6e66245efedbd6c070f9c0aee55
This was tested on Intel i7-4790K system with Mikrotik 10/25G NIC.
This was tested on Intel i7-4790K system with RB44Ge (AR8151 based 4-port NIC)
to verify backwards compatibility.
PR: 256000
Submitted by: Gatis Peisenieks <gatis@mikrotik.com>
MFC after: 1 week
Change-Id: I83cdeb24caccad15a9647a72159d979ecbd647f0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4361
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
could help with #16238
1/ iwn: adjust EEPROM read timeout for Intel 4965AGN M2
Reading EEPROM from Intel 4965AGN M2 takes 60 us which was causing panic
on system startup.
2/ from 561d34d705
The value for field "barker_mrc" of struct iwn2030_sensitivity_limits
was obtained from linux 3.2 wireless/iwlwifi driver code (iwl-2000.c:115
.barker_corr_th_min_mrc = 390).
Change-Id: I730bd6106e0d76da89fff041672ccbc4ef607976
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4359
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Change-Id: I6cb31760519c8ba4542d217d6e68439602eda558
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4356
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I4b8f69271ede117701725f9cce30de5bb8ba30bb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4332
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Built-in function call ffs() causing infinite recursion.
Change-Id: I506c0301c3a19178ebca4478cbe2ea06a7aeb932
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4318
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Make ISA bus optional in vesa driver
Change-Id: I1f38f92d81fbfe47224893e1d9dbf6a74306e2f0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3986
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I29b9676c6c2407e7795af4c7b1c56a7afb546f6e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4312
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* This gets the riscv64 build working again
* These changes are being consolidated into:
https://review.haiku-os.org/c/haiku/+/4309
Change-Id: I3b732299fa49acbda6317e6a2a8d7ab382d7740b
Improvements to the shutdown handling mechanics so that
if there is an install etc... happening when the
application is quit that it will wait until the process
is complete before actually terminating.
Change-Id: I8d3c4fbd9de0abc9382d55f0a6955b7f63a36637
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4322
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It allows to call destructor function stored in struct object such as
device_manager_info::put_node.
Change-Id: If9162f2f449d2b1c52c39509fa8732f21debf04a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3484
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The function was exited without releasing the 'device' pointer.
Change-Id: I19fcda340a6acf16c3fca243de6128d7218e379d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4282
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The function was exited without releasing the 'channel' pointer.
Change-Id: I093fbbc3c5c9c6633a8df8e04234a4076b1d7a05
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4281
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
We were not closing cd/dvd device after eject.
Also changed fDevice member to a local variable, since we only use it in one place.
Change-Id: I169da97501f98e30deded1f5ff53d3bc00459eab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4247
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Semaphore keys were added to the key map a bit early, before all error
checking had been done. As a result, we could have keys in the map that
would not point to a valid semaphore.
Fixes the root issue in #16741. A previous patch in hrev54878 had
already fixed the panic when trying to access such a key, but it was
still possible to generate one.
Change-Id: I7449e295fdbe2a48b554cbc0508683d042f6ca48
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4240
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Various functions would return an error if trying to use them on the
last page of userspace, as they tested the permissions for the first
byte out of the requested range. Also, the code was duplicated in
several places
- Rename validate_user_range to validate_memory_range. The "user" in the
name was to mean that the range is provided by the user calling the
syscall, but it is a bit confusing, as the function accepts any range
that is either in kernel or in user memory.
- Add a new function validate_user_memory_range that only accepts
userspace memory, and use this one where appropriate.
Change-Id: I135f8d584340f0ba4ae7e4b8cb6f8600fbf3ef2d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4212
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
- Remove Pause/Resume functions. They are not possible to implement (the
server would time out)
- Fix SetContext(NULL) to do the right thing.
Change-Id: I25ba09bb01ea0fe8a85d774611b33be7dc192028
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4245
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
We must keep an untranslated version of the text for use with the
expression parser. Only the key label in the user interface should be
translated.
Fixes #15709.
We have increased the number of default attributes, so the initial size
wasn't enough.
On small resolution displays, adjust the size to not end up with part
of the window outside the screen.
Fixes #15371
Change-Id: Ie59cb3a3f6609eff7d933d0bf0e11f66637d6d10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2222
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This is in the code to print a text dump of the layout constraints, so
it does not fix any layout problems, but it makes debugging things a bit
easier.
There was some confusion (and a TODO indicating it) in ServerFont.cpp,
because the notion of "font face" from the Be API is partially
implemented using different font manager styles (bold, italic, etc),
and partially by keeping flags in a separate variable for drawing
extra things or modifying the drawing (underscore, strikeout, ...).
The implementation did not actually preserve the extra flags, and so the
underscore face attribute was lost.
Implement the actual underlining of the text in AGGTextRenderer. This
implementation is a naive one so far. In particular there are the
following limitations:
1. Line is drawn over the text - no nice gaps for descents. Ideally, the
line should not touch the letter descents, and leave some space
around them. I don't know how to retrieve the contour - it appears to
me this might require bigger refactoring of this code. I have left in
my experiments commented out in the code.
2. If the text run ends with whitespace, the whitespace is not underlined
as it should. In particular if another text run is drawn next to it
and it's expected that the underline is continuous between the two.
Change-Id: I8d78b8e1eceddff0a7d98e5a49659e7b03fd89a0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3041
Reviewed-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This change aims to clean up the code a little. With explicit permission from Matthijs Hollemans.
Change-Id: Idd6c46b8059ec4674653a0d844502b4c76990726
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4146
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
as pointed out via cppcheck. Fix from upstream.
Change-Id: Idfb59ca86bb4ed3767d8327c145ad348cb645e24
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4216
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This switches to a new API format "v2" being introduced
on HDS. The version of the application is also bumped
at the same time in order to make a later cut-off point
possible for compatibility.
Change-Id: I577fd143ac9d001171bca7213c82e3280af1c4de
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4217
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The APIs for this were introduced in ICU 63, so we'll need an update.
ICU 63 does not build with gcc2, so this method is disabled there.
Change-Id: Iabe49509ed6d4e578560d497d3ca336a97db4625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1874
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Fixes:
* scsi: Fix a bug that caused the device capacity to be set
to an undefined value for some large SCSI devices when
READ CAPACITY (16) was used
* ahci: Fix VPD page reporting so that it does not return
undefined values
* ahci: Set the write bit to true when sending a DATA SET
MANAGEMENT (trim) command to a device. The command would
otherwise fail and time out on some devices.
Improvements:
* scsi: Extend the READ CAPACITY (16) support to also
include logical block provisioning information
* scsi: Prefer READ CAPACITY (16) over READ CAPACITY (10)
on devices that are expected to support this command
* scsi, ahci: Enable trim on SCSI and SATA devices that
are expected to support trim and which correctly report
trim support
* ahci: Redo the implementation of the SCSI UNMAP command
* scsi: Redo UNMAP-related code
* scsi: Add support for UNMAP via WRITE SAME (10) and
WRITE SAME (16) commands
* When copying trim ranges between different data types,
make sure that the values don't change (detect overflows)
* Report the number of trimmed blocks even if the trim
operation fails
Change-Id: Ie5fc993bbbc19546b4308138ba10184bf7b9986a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4157
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Fixes:
* Use uint64 instead of off_t when handling offset and size
of the trimmed range in the fs_trim_data structure
* BlockAllocator::Trim: Correct the size of a buffer
* ram_disk, mmc: Do not trim past device capacity
Improvements:
* BlockAllocator::Trim: Because the received offset and size
are ignored by BFS (the functionality is not implemented yet),
return B_UNSUPPORTED if the range does not cover the whole
partition
* ram_disk, mmc: More accurate calculation of the number
of trimmed bytes
* devfs: Add a uint64 version of translate_partition_access()
Change-Id: I24f4c08674f123ad33a5fef6e28996a4ada6ff0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4155
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
HTTP errors can have some content sent with them (a message to display
to the user, usually). The package kit would not ignore this and append
the content to the end of the downloaded file. This could result in a
file larger than the expected size, and in that case, it would keep
growing infinitely by adding more error messages to it.
Also add some more specific error messages for some HTTP codes, in
particular, "invalid range" which is likely to happen if something goes
wrong with range requests. Now this case will be detected and the
download will stop.
Change-Id: I18927f361235e9f72a5701c1bd7977abda9e21ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4210
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Integer overflow caused bitmap buffer creation of wrong size and out of
bounds access when large bitmap was created. Now allocation failure is
reported for large bitmaps.
This prevents app_server from crashing while playing YouTube in WebPositive.
Fixes #16489.
Change-Id: I297aa6e3b79b32a486d297f1239a1fd4397a8a36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4209
Reviewed-by: Sergei Reznikov <diver@gelios.net>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This update will mean that HaikuDepot is able to detect
install / uninstall actions on packages at the system
level and reflect this in the user interface.
Fixes #15879, #15994 and #15046.
Relates to #11674.
Also cleans up disused code in the WorkStatusView.
Change-Id: Ide2d5d93c2f71915bc7cfe7d3628e5f343e43f35
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4145
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Improvements:
* Introduce new command-line parameters for the offset and length
of the trimmed region
* Introduce a new command-line parameter that must be specified
in order to trim a block/character device instead of a file system
* By default, warn users that trim can potentially destroy data
* Display the number of bytes trimmed even if the ioctl returns
an error
Change-Id: I9eec535abe74f7ef09c927292a120016f4156684
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4154
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Check that the source and destination addresses in sg_memcpy
are not NULL. The absence of this check does not seem to
cause any issues, but I think it is safer to include it.
Change-Id: I2b04f94d5b04735fe9510adfb2400a7598b70bc4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4152
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
ICU's Locale::getDisplayName fills in the locale's name in the form
"language (country, variation)". We are interested in the country here.
Fixes #17081
Change-Id: Icb810dbe2c486d95251d4d06a48dfe3a000fa968
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4206
Reviewed-by: humdinger <humdingerb@gmail.com>
Pose::CalcRect() assumed top is at icon top in mini-icon mode. This
is not true for larger font sizes where the top of the text is above
the top of the icon. Calculate top and bottom based on font and icon
size matching the calculation in TextWidget::CalcRectCommon(). This
fixes a highlight redraw bug in mini icon mode at larger font sizes.
Push Edit name right 2px to match label position (in mini-icon mode.)
Round to integer to help with 1px off bug. Edit name box is still off
by 1px from the label for some font families and sizes.
Change-Id: Ibba897d6f3c7a879631adedada5cd59d2071191a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4204
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Use glyph 0 when no glyph is found for a character in the current font
nor any of the fallbacks.
HasGlyphs has to bypass LayoutGlyphs because we want it to mark this
case as false, while still checking the fallbacks.
Change-Id: Ief8d9d53c91992c659922fb56b79be7172f4ab0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The unofficial builds used %Distroname% directly and showed that to the
users, which does not look great. Instead use different wording that
simply avoids mentionning the OS name in de-branded builds.
- Small lingustic change: "Try Haiku" sounds a bit less awkward than
"Try out Haiku" and conveys the same exact meaning.
- Updated copyright note.
Co-authored-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Change-Id: Ic1be6bc4728946c19fc4fd162cfeea640c1f6c1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4036
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Allows invoking build tools at the command line without having
to mess with the LD library path environment variables
* Does not change the use of HOST_ADD_BUILD_COMPATIBILITY_LIB_DIR
within the build itself
* Darwin currently excluded, as it uses a different method for
specifying rpath
Change-Id: I4db443f2b5824ee70ad44418251a9996c14663bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4163
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>
* Fixes the riscv64 build
* Should fix next_m68k loader (untested)
Change-Id: Ic9b2d4305302d28a9ca0c71f8e1e502c763162d9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4199
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* platform_add_block_devices() is a no-op, as efi already
provides all devices to the generic loader code.
* remove iterator.Remove() in platform_get_boot_partitions()
as the simplified devices scan no longer duplicates
partition entries.
Fixes #17051
Change-Id: I38789b069e1be9b18312e2455bc91e6195114599
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4160
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Makes the case where the loader and the install differ by
release type, so that the icons are rendered in the same
position
Change-Id: I01e48109ce127b202ce5e05544aa2d5a495ed53e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4162
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>
* Haiku now consumes right at 700 MiB on x86_gcc2h
after the webkit update.
Change-Id: Ia41a3e6252190e73feaa49ebe7c58ef4c80df4dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4161
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This patch fixes compilation errors on x86_64 when TRACE_DEVFS
is defined. Only format identifiers that caused compilation
errors are changed. Commented-out TRACE's are left unchanged.
Change-Id: I4e803920665eaac7fbc5cec2ffb7778c262bf9c0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4151
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
This also keeps the functionality of hrev53848, which simplifies the
list of disks searched for bootable partitions; however, it maintains
the previous behaviour of platform_get_boot_partitions that continues
to iterate over a list of possible boot partitions, which should
allow finding a bootable BFS partition better in more circumstances.
Particularly, there are numerous reports of the UEFI loader entering
the boot menu despite it finding a bootable partition, which this
should address.
EFI's device_contains_partition is also structured such that it
compares the disk GPT table of the partition the loader is
querying of the EFI disk's GPT table, in the case that there are
multiple disks, as the most reliable method of comparison, with
a generic fallback for non-GPT disks, which will be less reliable.
This reverts commit 0d932a49ad.
Change-Id: I5fac8608035d56b8bb4dc6c3d495ec6db42fa9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4149
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
We were incorrectly reporting a B_IO_ERROR for these requests because we
could not read the content after the headers. There is no content in
these cases.
Add an unit test for both HEAD and 204 status, checking that there is no
content and the headers are correct.
Fixes #16885.
Change-Id: I98fefc5c604253bb2545b50395b7af9f8834def0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4142
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Update the package server so that it reports the
added and removed packages when it commits a
change so that clients are able to pickup and
act on the changes without iterating over all of
the packages.
Change-Id: I6feb52c34fc51a78e2282d8d5ca6cb6775b221ca
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4141
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Screen may be turned off if video card is not supported by firmware and boot
loader.
Change-Id: Ie60fc00da281ec3781084dd97466a68b885fde7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4114
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- This will fix page translation fault when accessing
static variables.
- Now with this patch, we made uart pl011 works for qemu.
Change-Id: I8eecc18ad05bd950768b49d9ed268c4c2a3baf25
Signed-off-by: Han Pengfei <pengphei@qq.com>
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4123
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: X512 <danger_mail@list.ru>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This patch adds the functionality to read B+Trees based files.
It shares similarity with extent based file reading functionality. Just
the way the extents are read is different.
Change-Id: I9b7ebe20171a8860fdc35024f7018540248aed61
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3170
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
EFI System Partition was the last remaining holdout for mtools usage.
Change-Id: I988f82a2f4318f2f90ec1efb80f7ff5c8908aff7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4140
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Nothing really refers to libunwind anywhere in Haiku, so it's likely as good as gone.
Change-Id: I1b9a2e23558caa46211c81618295361748344441
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4128
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The code allowed execution to continue as soon as the "command inhibit"
bit was cleared. This is incorrect: we need to wait for a command result
(either command complete, or timeout) to be available before continuing.
This should fix #17031.
Change-Id: I8f3fe60c2e47582b399952b19c05c6ed2161afd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4121
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: I854de44c1b31066dfa522b946cb04a5190f6b0b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4113
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Off-by-one error copying the string.
* As per the spec, return the buffer length for the string when passed a
null pointer and 0 length.
Fixes https://github.com/haikuports/haikuports/issues/5821
Change-Id: Ic421f26db00f9820c6a617375e39f7341cd5ebc1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4110
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It cause per-byte access instead of 32 bit on GCC/riscv64 that breaks operation.
All fields are 32 bit so alignment is already fine and packing is not needed.
Change-Id: Ie96eac6615c9326e84608be1c667bc5d3600c508
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4117
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This was based on the FreeBSD wi driver. The FreeBSD driver is removed
in FreeBSD 13. Most of the supported hardware was PC-Card, which we
never supported in the first place. All the devices, even the few
supported PCI ones, are restricted to 11Mbps Wifi, and the driver never
supported WPA. This makes this hardware largely irrelevant today.
The driver had already been removed from the build. This ocmmit just
deletes the sources.
Fixes #16942.
Unify the background processing in the
application to one system and refactor
the package actions. This won't fix
any specific current issues with this
area, but lays the ground for later
fixes.
Change-Id: I098b81e7afc4aeb883bddf1acfc01f7888134257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3997
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
- New text/markdown MIME type was added according to IANA registry.
- MIME types gained new extensions that weren't previously included.
- Resource definition files will now open up with Pe by default.
- text/x-vcard was renamed to text/vcard, as it's now a registered IANA MIME type.
- text/x-source-code had its sniffing rules increased in priority,
so that it would get precedence over text/plain and its own sniffing rules.
Change-Id: I28af24de8c0e96ef39dfc67703a0884e8d4c842e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4109
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Fix part of #17023
* Update default server to "gnudb.gnudb.org:80".
* Add "/" to command footer to work with gnudb.
Change-Id: I363ca919d971e96ba27476a56ca06b4e8fa99171
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4112
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
There are 2 issues right now. One is that I have to give cat command the
entire file size for it to print the entire file. The second issue is
that I am getting segmentation fault for some reason, and it doesn't
even have to do with xfs_read().
For more info: https://review.haiku-os.org/c/haiku/+/3154
Change-Id: I8e3acd658730ed2339dabbd671820c409332f296
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3154
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Solves out of space issue building release images
Change-Id: I888836774732f65fde3574ef498b272d8285356f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4107
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This resolves the confusion about the "url" field in repository
definition files. However it changes the identifier of repositories. It
seems to be a good idea to do this with a new release, as users will
need to switch to new repos anyway and can accept special instructions
at that time (we will include the instructions in the release notes).
The new format uses a tag: uri as specified in https://tools.ietf.org/html/rfc4151
The rationale for this is:
- We need a way to uniquely identify repositories
- We want anyone to be able to create a repository easily, with no
central registration, and in a way that does not results in accidental
conflicts. We do not want to be running a registry to grant people an
identifier for their repository.
- Backwards compatibility with existing repositories and software should be
preserved: some code and file formats in Haiku package tools expect or
expected the identifier to be parsable as a BUrl. Existing 3rd-party
repositories use an http or https URL as an identifier and may
continue to do so (changing the identifier of existing repositories is
not desirable)
- Forwards compatibility if we want to change this again later
- Optional: repository identifiers should be user readable.
The tag: URI resolves this in the following way:
- Backwards compatibility: it is still an URI, as the identifier
previously was.
- Forward compatibility: We can change to another URI scheme if we want to.
In fact, each repository can decide what type of URI they want to use,
"tag" is only a recommendation and put in use for the repos we
provide.
- Uniqueness + no centralization: the tag: URI specifies namespaces tied
to a domain name (which is already needed to host a repository) and a
date at which the domain is owned by the entity generating a tag. Inside
that namespace, they can do as they wish.
- User readability: the format is simple and text-based.
Other possible alternatives are:
- keeping the current solution of using http URLs. It has proven
confusing because the repository hosting may be moved or mirrored
while preserving the identifier. There is also work in progress to
distribute packages using other protocols (eg. IPFS).
- Using an uuid. This provides unique, decentralized identifiers, but
is not user-readable. Backwards compatibility can be provided by
wrapping the uuid into an "urn:uuid:" URI (see
https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx).
- Using some other URI scheme such as "urn:oid:". I investigated some, but
found none that provide a decentralized namespacing solution (except
for "tag", of course).
- Using a custom URI scheme of our own. This would normally require declaring
it to the IANA (example: https://www.iana.org/assignments/uri-schemes/prov/apt
for Debian packages) in order to not make the internet more of a mess
than it already is. We would still need to define a way to generate
URIs that protects people from getting accidental conflicts. The
solution would probably be similar to what the "tag" URI scheme does, as
there doesn't seem to be many other ways to guarantee uniqueness in
(cyber)space and time without registration.
- Not using an URI scheme: in addition to the problems of a custom URI
scheme, this would break backwards compatibility (existing software
would not accept the new format) and forwards compatibility (without a
scheme in the identifier, it is hard to detect what it is supposed to
be if we change formats later on)
Change-Id: I970c23a546569994632c7bd570d11bdea95ba52e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4106
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This reverts hrev54422.
I'm not sure what I was trying to fix with this change. The way the
media kit is currently designed, the list of supported formats
(including for reading) comes only from writer plugins. This means it is
impossible to have a decode-only plugin currently. And the list is
called "fWriterFileFormats" but in fact is the only list used to
implement get_next_file_formats, so it should contain all formats.
This current setup works for the ffmpeg plugin, but it should be
cleaned.
This fixes Youtube playback. The problem was simply that we were not
reporting support for any of the Youtube video formats anymore.
Unfortunately, the app_server crashes when playing Youtube videos are
still there.
Change-Id: Ie5025cd48e2ab23b616bad49eec1401331ffb0ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4103
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Panagiotis Vasilopoulos <hello@alwayslivid.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Theorically we could define __STDC_NO_THREADS__ internally in GCC, but
threads.h probably will be added in the future, and the compiler won't
notice.
Using this stdc-predef.h header and including it in GCC would solve this
nicely, and saves us from hardcoding.
The header can eventually be removed when obsolete.
Change-Id: I29aa58686e3c45449dc63e02e5a9e13a960b9090
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4097
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Don't resize text view in FrameResized() if resizable, this is done
in _AutoResize() instead. Set text rect width to width of max line when
word-wrap is off. Text rect width shrinks to the width of the text
matching behavior of BeOS R5 and previous Haiku. This fixes Tracker
Edit name.
Limit max width to column width in list mode or 30em in icon mode.
Filter paste messages limiting to max width in Tracker Edit name.
General BTextView fixes:
As a consequence of the text rect shrinking to fit the text, adjust
highlighting to go at least to edge of the view even if text rect width
is narrower. Extend the invalidation area beyond text rect when
redrawing to include highlighted areas.
Text views behave properly when overflow occurs i.e. when you type
text off the end of the text view. The text is nudged over as you
type/scroll so that the previous text is visible. This sorta worked
before but now works better.
Fix text rect centering by replacing switch with
BLayoutUtils::AlignOnRect().
Coalesce consecutive draw calls when inserting and deleting text to
prevent flashing for example when resizing the window. Redraw text
when the text view scrolls fixing a bug I noticed in StyledEdit.
Workaround negative height Beezer bug.
Fixes #16642, #16476
Change-Id: I2d32d6039944d2dc3218ce4de71f2966cc98c866
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3642
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
POSIX defines this structure but specifies only two fields (which we
already implement). However, both the *BSD and Linux have agreed on
some more fields, which are often assumed to be there by applications.
The benefice of having compatibility fields is
greater as having to patch every other software at HaikuPorts.
Change-Id: Ie28ca2e348aa16b4c57eb3498eb62175100d9b9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4083
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
In the case that an application is blocked by a model panel during shutdown, the icon will now show a "waiting" animation
like in BeOS R5.
Fixes #7980
Change-Id: Iec79fcaf431407ff51430a1a8e4c8ec41571059d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4001
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Previously, hrev55011 introduced localization for Cortex, which then
prompted to close #7530. It has then been reopened, when it turns out
that the translations for the container application (RouteApp) did not
work, whereas the individual add-ons/modules were translated.
The cause is that by default BCatalog looks up the translations based on
the subtype part of the signature. This is x-vnd.Cortex.Route (without
the application/ supertype). This change will place the translations in
the right place of the file system.
The add-ons were never affected, since they BCatalog is explicitly told
to find the translations for the entire signature, like:
static BCatalog sCatalog("application/x-vnd.Cortex.InfoView");
Even so, it was chosen to omit the `application` supertype from the
signature for the shared code as well.
This should fix #7530 for good.
Change-Id: Iff18fabef7aba68602e49db1e98cfed2f486f545
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4091
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
inspired by hrev23436, fix #10944
Change-Id: Ieedace86a6541a4cd1346791146a96e99d09d614
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4093
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This should allow easier porting of things like flashrom,
as it mimics FreeBSD's /dev/io behaviour.
Change-Id: Iaa6b6342cf7983a9655a7155adfcc46c8a8264f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1077
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
- It's a good idea to push interested parties towards the right direction.
Change-Id: Ib2486f981c1abbccf97ac019bee919bdf92279e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4089
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Not sure why it only ever allowed a single instance.
Change-Id: I972a1d601d93725674a97fb341aa7ffb3625b105
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1075
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: I7bf7d5dac5bb576f9ca5fc55680fc369556f4312
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4044
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The GetNext() works well for B+Trees and that wraps up the work needed
for all kinds of GetNext().
Change-Id: Ie965d3da273364f8fdbdb8faee5cb3c214881130
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3124
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Arrow keys are not available on some platforms.
Change-Id: Ia38797eb12202668a0b0976b31f21f564d140901
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4087
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
This was enabled per-architecture, but it is reasonable to always
enable GPT support for all EFI systems, no matter which CPU is used.
Change-Id: I53ca2caf048fbc4ead6cfb74c8734ac9ad382224
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4085
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Fix 'flags' was not used in In KeyboardLayoutView::_DrawKeyButton().
Pointed by Clang Static Analyzer.
Change-Id: Ic3b2da856ee410e908eaaf0c5c4b5b3753928c00
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4079
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* We accept the riscv loader to build it, but don't really put it
into the image since for now you'll just want the haiku_loader.riscv
for things like TinyEMU
Change-Id: I5005dd5063f2a84cf426db4c40635e87e579ad80
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4075
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>
When the screenshot is changed to a new one, it resets the size
before the screenshot begins downloading so the window is not the
same size as the previous screenshot.
Change-Id: I778b241537b3d1eeb1c1f91b60c60f5e8509ee51
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4049
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
this is what's generally done on other OSes.
Change-Id: I90f1a574172b8e020c9943468d2fd121e14dd062
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4047
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
User threads aren't supposed to be able to adjust the interrupt flag (IF). A few
apps for instance DOSBox would just use the popf instruction and disable the
flag, expecting the change to be ignored.
Quote from the Intel manual:
"The interrupt flag (IF) is altered only when executing at a level at least as
privileged as the IOPL. If a POPF/POPFD instruction is executed with
insufficient privilege, an exception does not occur, but the privileged bits
do not change."
fix #14711
Change-Id: I0519312c1151a1dd76541f60283c6c210a5b21a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4046
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We can now read all the extent maps from the leaves. This will be needed
to implement the GetNext() functionality.
Change-Id: Ie10b453c33bec6e6d3109743d695f86a90de45cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3119
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Expands on previous change to no enter a stopped
state on an endpoint teardown.
* Doorbells could re-awaken the port in a stopped state
Change-Id: Ib5d9c89c4b721ea36ca22aaaf3ff92760a3ec2ff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3996
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>
FreeType only provides some font parameters for scalable fonts. In
particular, we use the FT_Face values of units_per_EM, ascender,
descender and height, which are 0 for bitmap-only fonts.
Part of #16938.
Change-Id: Iea2d87ad95f3bc1c2e27fb041da0a27c6e68be91
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4042
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This will break previus ways to store settings (as it only stored a struct)
* Now we use BMessage to save data.
* Added some stuff to SettingsMessage.
* Fix a bug in BluetoothSettingsView::_GetClassForMenu() and SettingsMessage::SetValue
Change-Id: I6a0fa1564e78460258f480947592eb4007985007
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3887
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
`frame_buffer_console` is not usable in boot loader because it use
kernel virtual memory API.
Change-Id: I83f7411261e2ed9b4d68d4c109e5d988e75042cb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4013
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Problems found by running haiku-format and looking at the resulting
files. Manually triaged to keep only the correct changes, currently
haiku-format is making a lot of unwanted changes as well.
Merging the correct changes allows us to see the incorrect ones more
easily and continue working on fixing them.
the AC flag in eflags/rflags, pushed in the iframe by the CPU, is kept intact after handling the exception, since the fault handler is run with the faulted iframe and does a simple jump. The AC flag would otherwise be set until the syscall returns to userland.
Change-Id: I24f763032ab98029dd162fb411e1541586451606
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4040
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It is not present in BeOS R5 and it just call unload_driver_settings.
Replace delete_driver_settings usages with unload_driver_settings.
Keep the symbol on x86 for binary compatibility.
Change-Id: I1382710e3a4cb5c65d1249ea0e5880891e6800e4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3485
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
only available on gcc 4 and upper.
Change-Id: Ifc059d5fedd15a5aeda1514312fbbf98a72d3128
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4005
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Use this larger font when the screen resolution is large (more than
1920x1080 in both directions). The usual font is too small and not easy
to read on such high resolution displays.
Change-Id: I14a40ecf6917d0c6c64ab5a8abe1affcb3839a74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3818
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It cause adding new entry to executable init array for each translation unit.
Change-Id: I1e2d7946da03c001de7721948bc9af8188e8b317
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3981
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* As per the spec, the only exit from an endpoint in a halt
state is to issue a restart command. (restart puts the endpoint
into a stop state.. it's named poorly)
Change-Id: I4a1a556374ad7f564a562d995d1a2e29230a50c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3959
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This reverts commit dfc8e52638.
It needs more attention to its influence on other parts of the code.
Fixes #16954
Change-Id: Ibb764d81666434a198023bc345a45ef9d270eadb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3976
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This is getting more common in tablets and laptops. It replaces PS/2 for
the internal keyboard and pointing devices. This is simpler and cheaper
than using up USB ports, and also simpler than the old and quirky PS/2
protocol.
The HID spec is the same no matter what transport is used (it is also
applicable for Bluetooth). Ideally we could create a separate HID bus
manager that would handle all these devices in a generic way, but that
is a lot of work nad extra complications for uncertain gains.
For now, just move the common files to a shared directory where both
drivers can use them. As a result the files are compiled twice, which is
what we want, because currently they hardcode some device paths that
need to be different for each driver.
Change-Id: I0327f6864dd0a4372b708f7b7ecf299aa86a6ea9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2466
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
654517304167bb4675aa14ada0a1dac9efe71c9b Convert to if_foreach_llmaddr() KPI.
5ab0c8434a7befeafbaf81e899fc23f660b64c9d ath(4) processing input packets in taskqueue.
6c3e93cb5a4aa4b8a2d8d4d326f2a7c34d3a4458 Use NET_TASK_INIT() and NET_GROUPTASK_INIT()
add extra ANI fields for the AR9300 HAL.
I'm trying to debug why reception upstairs here is so terrible and it
turns out ANI is buggy. (Which is no surprise, ANI is always buggy.)
Tested:
* Carambola2 (AR9331), STA/AP modes
ANI fixes and preparation for userland control.
* The ani function bitmap was being badly used when determining if a command
could be used. In hostap modes only a couple of the ANI control parameters
are enabled.
* The ani function bitmap was not being reset to HAL_ANI_ALL if transitioning
from AP -> STA.
* Change mrcCckOff to mrcCck - 1 == on, rather than 1 == off. This matches
the API used to set the value from userland via the diagnostic API.
* Handle OFDM/CCK noise immunity level commands in ar9300_ani_control().
These will only come from userland and it will go and program the rest of
the ANI control parameters with the values in the ANI table.
* Ensure all of the ANI parameters can be tweaked at runtime, even if they're
disabled.
Tested:
* carambola2 (AR9331), STA/AP modes
Fix return value check to not complain.
Compilers complain more about things, so let's keep them happy.
Extend the start PCU receive to handle resetting ANI.
One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when channels were
changed. If you're on a really crappy channel and ANI has made
you deaf then when you scan you continue to be deaf on all channels.
This code passes in a flag to startpcureceive which in AR5416 and later
is also used to enable ANI. This allows it to know if it's a normal
operation or a scan operation.
This fixes my situation at home where a temporary spot of a device
going deaf due to interference starts scanning and .. can't hear
anything until I restart.
Now, this isn't the full fix - ideally:
(a) all the ANI config and per-channel information would be migrated
to the shared HAL stuff and enabled for all of the NICs;
(b) when a station reassociates and some other error conditions
(like missed beacons, NF calibration failures, etc) a knob
to reset ANI parameters would likely help recovery.
But hey, I'm committing bits of code again! woo!
Tested:
* AR9344 (2G), STA operation
Fix ANI calibration during non-ACTIVE states; start poking at rate control
These are some fun issues I've found with my upstairs wifi link at such a ridiculous
low signal level (like, < 5dB.)
* Add per-station tx/rx rssi statistics, in potential preparation to use that
in the RX rate control.
* Call the rate control on each received frame to let it potentially use
it as a hint for what rates to potentially use. It's a no-op right now.
* Do ANI calibration during scan as well. The ath_newstate() call was disabling the
ANI timer and only re-enabling it during transitions to _RUN. This has the
unfortunate side-effect that if ANI deafened the NIC because of interference
and it disassociated, it wouldn't be reset and the scan would never hear beacons.
The ANI configuration is stored at least globally on some HALs and per-channel
on others. Because of this a NIC reset wouldn't help; the ANI parameters would
simply be programmed back in.
Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe,
if I'm feeling clever, I need to reset the ANI parameters on a given channel
during a transition through INIT or if the VAP is destroyed/re-created.
However for now this gets me out of the immediate weeds with connectivity
upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this
stuff up in subsequent commits.
Tested:
* AR9344 (Wasp), 2G STA mode
Have the final attempted rate in 11n modes to be the lowest one.
Right now ath_rate_sample has a fixed rate schedule, rather than the minstrel_ht
style "best, good, most reliable" triplet. So, if higher rates are tried then
it'll not fail back to a lower MCS rate in that transmission schedule.
This means that in low SNR situations it'll not easily drop to MCS0 unless enough
transmissions occur to allow rate control to eventually decide to drop; and if
it's TCP traffic it'll get slowed down because of packet loss.
It's worse for 2-stream and 3-stream rates; it doesn't ever fall back to lower
stream rates, and these higher stream rates required higher SNR to work.
So instead let's (for now?) have each of the 11n transmit rates use MCS0 as
the last attempt. ath_rate_sample will quickly see that rate succeeds more
and will move to it much quicker.
Testing:
* AR9344 (Wasp) - 2G STA mode
Fix queue bits a bit
Found by PVS Studio: duplicate assignment; add assignment of tqi_compBuf.
Submitted by: <mizhka@gmail.com>
Differential Revision: https://reviews.freebsd.org/D20431
ath_hal: fix typo in ath_hal_printf
Fix endian macros to work in and out of kernel tree.
Yes, people shouldn't use bitfields in C for structure parsing.
If someone ever wants a cleanup task then it'd be great to remove them
from this vendor code and other places in the ar9285/ar9287 HALs.
Alas, here we are.
AH_BYTE_ORDER wasn't defined and neither were the two values it could be.
So when compiling ath_ee_print_9300 it'd default to the big endian struct
layout and get a WHOLE lot of stuff wrong.
So:
* move AH_BYTE_ORDER into ath_hal/ah.h where it can be used by everyone.
* ensure that AH_BYTE_ORDER is actually defined before using it!
This should work on both big and little endian platforms.
Add some extra data into the rate control lookup.
Right now (well, since I did this in 2011/2012) the rate control code
makes some super bad choices for 11n aggregates/rates, and it tracks
statistics even more questionably.
It's been long enough and I'm now trying to use it again daily, so let's
start by:
* telling the rate control code if it's an aggregate or not;
* being clearer about the TID - yes it can be extracted from the
ath_buf but this way it can be overridden by the caller without
changing the TID itself.
(This is for doing experiments with voice/video QoS at some point..)
* Return an optional field to limit how long the aggregate is in
microseconds. Right now the rate control code supplies a rate table
and the ath aggr form code will look at the rate table and limit
the aggregate size to 4ms at the slowest rate. Yeah, this is pretty
terrible.
* Add some more TODO comments around handling txpower, rate and
handling filtered frames status so if I continue to have spoons for
this I can go poke at it.
Extend ath_rate_sample to better handle 11n rates and aggregates.
My initial rate control code was .. suboptimal. I wanted to at least get MCS
rates sent, but it didn't do anywhere near enough to handle low signal level links
or remotely keep accurate statistics.
So, 8 years later, here's what I should've done back then.
* Firstly, I wasn't at all tracking packet sizes other than the two buckets
(250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and
65536. I may go add 2048 at some point if I find it's useful.
This is important for a few reasons. First, when forming A-MPDU or AMSDU
aggregates the frame sizes are larger, and thus the TX time calculation
is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels
isn't some fixed thing, both due to channel conditions and radios themselves.
Notably, there was some observations done a few years ago on 11n chipsets
which noticed longer aggregates showed an increase in failed A-MPDU sub-frame
reception as you got further along in the transmit time. It could be due to
a variety of things - transmitter linearity, channel conditions changing,
frequency/phase drift, etc - but the observation was to potentially form
shorter aggregates to improve BER.
* .. and then modify the ath TX path to report the length of the aggregate sent,
so as the statistics kept would line up with the correct bucket.
* Then on the rate control look-up side - i was also only using the first frame
length for an A-MPDU rate control lookup which isn't good enough here.
So, add a new method that walks the TID software queue for that node to
find out what the likely length of data available is. It isn't ALL of the
data in the queue because we'll only ever send enough data to fit inside the
block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr()
would do.
* .. and cache that in the first ath_buf in the aggregate so it and the eventual
AMPDU length can be returned to the rate control code.
* THEN, modify the rate control code to look at them both when deciding which bucket
to attribute the sent frame on. I'm erring on the side of caution and using the
size bucket that the lookup is based on.
Ok, so now the rate lookups and statistics are "more correct". However, MCS rates
are not the same as 11abg rates in that they're not a monotonically incrementing
set of faster rates and you can't assume that just because a given MCS rate fails,
the next higher one wouldn't work better or be a lower average tx time.
So, I had to do a bunch of surgery to the best rate and sample rate math.
This is the bit that's a WIP.
* First, simplify the statistics updates (update_stats()) to do a single pass on
all rates.
* Next, make sure that each rate average tx time is updated based on /its/ failure/success.
Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS
12 would have their average tx time updated for /their/ part of the transmission,
not the whole transmission.
* Next, EWMA wasn't being fully calculated based on the /failures/ in each of the
rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure
that the statistics noted that /all/ subframes failed at those rates, rather than
the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average
TX time are updated correctly.
* When picking a sample rate and initial rate, probe rates aroud the current MCS
but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things
like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial
streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at
MCS8 then don't probe MCS7 as part of it, it's not likely to succeed.
* Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS
rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and
.. then each comparison would accept the higher rate. Just skip those; sampling
will fill in the details.
So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of
instability around higher MCS rates because there are bursts of loss/retransmissions
that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks.
Ok, so why this still something I'm poking at? rather than porting minstrel_ht?
ath_rate_sample tries to minimise airtime, not maximise throughput. I have
extended it with an EWMA based on sub-frame success/failures - high MCS rates
that have partially successful receptions still show super short average frame
times, but a /lot/ of retransmits have to happen for that to work.
So for MCS rates I also track this EWMA and ensure that the rates I'm choosing
don't have super crappy packet failures. I don't mind not getting lower
peak throughput versus minstrel_ht; instead I want to see if I can make "minimise
airtime" work well.
Tested:
* AR9380, STA mode
* AR9344, STA mode
* AR9580, STA/AP mode
le oops, trim out an #if 1 that I didn't fully delete.
Cool, so now I know it's about 3 weeks between starting on freebsd coding
and breaking the build again. Queue dunce cap.
Fix logic for determining whether to bump up an MCS rate.
* Fix formatting, cause reasons;
* Put back the "and the chosen rate is within 90% of the current rate" logic;
* Ensure the best rate and the current rate aren't the same; this ...
* ... fixes the packets_since_switch[] tracking to actually conut how many
frames since the rate switched, so now I know how stable stuff is; and
* Ensure that MCS can go up to a higher MCS at this or any other spatial stream.
My previous quick hack attempt was doing > rather than >= so you had to go
to both a higher root MCS rate (0..7) and spatial stream. Eg, you couldn't
go from MCS0 (1ss) to MCS8 (2ss) this way.
The best rate and switching rate logic still have a bunch more work to do
because they're still quite touchy when it comes to average tx time but at least
now it's choosing higher rates correctly when it wants to try a higher rate.
Tested:
* AR9380, STA mode
Limit the tx schedules for A-MPDU ; don't take short retries into account and remove the requirement that the MCS rate is "higher" if we're considering a new rate.
Ok, another fun one.
* In order for reliable non-software retried higher MCS rates, the TX schedules
(inconsistently!) use hard-coded lower rates at the end of the schedule.
Now, hard-coded is a problem because (a) it means that aggregate formation
is limited by the SLOWEST rate, so I never formed large AMDU frames for
3 stream rates, and (b) if the AP disables lower rates as base rates, it
complains about "unknown rix" every frame you transmit at that rate.
So, for now just disable the third and fourth schedule entry for AMPDUs.
Now I'm forming 32k and 64k aggregates for the higher density MCS rates
much more reliably.
It would be much nicer if the rate schedule stuff wasn't fixed but instead
I'd just populate ath_rc_series[] when I fetch the rates. This is all a
holdover of ye olde pre-11n stuff and I really just need to nuke it.
But for now, ye hack.
* The check for "is this MCS rate better" based on MCS itself is just garbage.
It meant things like going MCS0->7 would be fine, and say 0->8->16 is fine,
(as they're equivalent encoding but 1,2,3 spatial streams), BUT it meant
going something like MCS7->11 would fail even though it's likely that
MCS11 would just be better, both for EWMA/BER and throughput.
So for now just use the average tx time. The "right" way for this comparison
would be to compare PHY bitrates rather than MCS / rate indexes, but I'm not
yet there. The bit rates ARE available in the PHY index, but honestly
I have a lot of other cleaning up to here before I think about that.
* Don't include the RTS/CTS retry count (and thus time) into the average tx time
caluation. It just makes temporarily failures make the rate look bad by
QUITE A LOT, as RTS/CTS exchanges are (a) long, and (b) mostly irrelevant
to the actual rate being tried. If we keep hitting RTS/CTS failures then
there's something ELSE wrong on the channel, not our selected rate.
Fix correct status when completing frames with short failures.
My preivous logic was a bit wrong. This caused transmissions that failed due
to a mix of short and long retries to count intermediate rates as OK if the
LONG retry count indicated some retries had made it to this intermediate rate,
but the SHORT retry count was the one that caused the whole transmit to fail.
Now status is passed in again - and this is the status for the whole transmission -
and then update_stats() does some quick math to see if the current transmission
series hit its long retry count or not before updating things as a success
or failure.
Obey the maximum frame length even when using static rates.
I wasn't enforcing the maximum packet length when using static rates
so although the driver was enforcing it itself OK, the statistics were
sometimes going into the wrong bin.
Tested:
* AR9380, STA mode
reset hardware if this particular mac bug is seen.
I have to dig into why I'm seeing it on chips as late as the AR9380 era
stuff (as it's marked as an AR5416 bug, but who knows!) but i'm seeing
aggregate TX frames complete with no blockack bit set. So, everything
should be treated as a failure and do a hardware reset for good measure.
Tested:
* AR9380, STA mode
* AR9580 (5GHz), AP mode
Hopefully recover better-er upon RX restart on AR9380.
This is all very long-standing bug stuff that is touchy and still poorly
documented. Ok, here goes.
The basic bug:
* deleting a VAP causes the RX path (and TX path too) to be restarted
without a full chip reset, which causes RX hangs on the AR9380 and later.
(ie, the ones with the newer DMA engine.)
The basic fix:
* do an RX flush when stopping RX in ath_vap_delete() to match what happens
when RX is stopped elsewhere. This ensures any pending frames are completed
and we restart at the right spot; it also ensures we don't push new RX buffers
into the hardware if we're stopping receive.
The other issues I found:
* Don't bother checking the RX packet ring in the deferred read taskqueue;
that's specifically supposed to be for completing frames rather than
just yanking them off the receive ring.
* Cancel/drain any pending deferred read taskqueue. This isn't done inside
any locks so we should be super careful here. This stops the hardware
being reprogrammed at the same time in another thread/CPU whilst we're
stopping RX.
* .. (yes, this should be better serialised, but that's for another day. maybe.)
* Add more debugging to trace what's going on here.
And the fun bit:
* Reinitialise the RX FIFO ONLY if we've been reset or stopped, rather than just
reset. I noticed that after all the above was done I was STILL seeing RXEOL.
RXEOL isn't enabled on the AR9380 so I'd only see it if I was sending TX frames
(ie a ping where it'd be transmitted but never received) so I was not being
spammed by RXEOL. So, as long as stuff is stopped, restart it.
This seems to be doing the right thing in both AP and STA modes.
What I should do next, if I ever get time:
* as I said above, serialise the receive stop/start to include taskqueues
* monitor RXEOL on the AR9380 and I keep seeing it spammed / lockups, just
go do a full chip reset to get things back on track. It sucks, but it
is better than nothing.
Tested:
* AR9380 AP/STA mode, adding/deleting a hostap VAP to trigger the TX/RX
queue stop/start; whilst also running an iperf through it. Lots of times.
Lots. Of.. Times.
Propagate the HAL_RESET_TYPE through to the chip reset; set it during ath_reset()
Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both throughout the HALs and in if_ath.c.
This will eventually deprecate the ath_hal force_full_reset option
because it can be requested at the driver layer.
So:
* Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type
* Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset
* Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions
* Use HAL_RESET_NORMAL in most calls to ath_reset()
* .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs.
This should be a glorified no-op outside of actual hardware issues.
I've tested things with ath_hal force_full_reset set to 1 for years now,
so I know that feature and a full reset works (albeit much slower than
a warm reset!) and it does unwedge hardware.
The eventual aim is to use this for all the places where the driver
detects a potential hang as well as if long calibration - ie, noise floor
calibration - fails to complete. That's one of the big hardware related
things that causes station mode operation to hang without easy recovery.
Differential Revision: https://reviews.freebsd.org/D24981
Update ath_rate_sample to use the same base type as ticks.
Until net80211 grows a specific ticks type that matches the system,
manually use the same type as the kernel/net80211 'ticks' type
(signed int.)
Tested:
* AR9380, STA mode
Don't re-program the beacon timers if we miss a beacon in software-beacon STA mode.
This is something I added a few years ago to handle resyncing the beacon if
we miss a beacon or need to sync after association/reassociation/powersave.
However, if we're doing STA+AP mode (eg DWDS) then we don't want
to reprogram the beacons here; this may upset normal AP operation.
I missed checking for the sc->sc_swbmiss flag so I was reinitialising
the beacon timers after every beacon miss / TSFOOR option, and
that isn't likely good.
This plus ensuring that STA's are created with "-beacon" to disable
BMISS/TSFOOR processing will hopefully quieten some of the issues
I've seen with missed beacons / TSFOOR (out of range) interrupts
coming in when operating in STA mode.
Tested:
* AR9380/AR9580, STA+AP modes
Don't update the beacon bits from beacon frames in hostapd mode.
This logic is running the beacon receive bits in STA+AP mode on both the
STA and AP side. The STA side sees its beacons from the BSS fine; the
AP side is seeing other beacons on the same channel but with the BSS
node for some odd reason. (I think it's a valid reason, but I currently
forget what that valid reason is.)
So, just to be cleaner about things, don't run the nexttbtt/etc bits
at all if we're in hostap mode. If I ever get mesh working then maybe
I'll make sure it works right on mesh+ap and mesh+sta modes.
Whilst here, log the VAP i'm being called on to make it clearer what
is going on. I may end up adding a VAP dprintf version of this at
some point.
Tested:
* AR9380, STA (DWDS client) + hostap on the same NIC
Add KeyMiss for AR5212/AR5416 series chips.
This is a flag from the MAC that says the received packet didn't match
a keycache slot. This isn't technically a problem as WEP keys don't
match keycache slots (they're "global" keys), but it could be useful
for tracking down CCMP decryption failures.
Right now it's a no-op - it mirrors what the AR9300 HAL does and it
just increments a counter. But, hey, maybe one day I'll use it for
diagnosing keycache/CCMP decrypt issues.
ath: clean up empty lines in .c and .h files
replace the hard-coded magic values in if_athioctl.h with constant defines
Replace some hard-coded magic values in the ioctl stats struct with
defines. I'm going to follow up with some more sanity checking in
the receive path that also use these values so we don't do bad
things if the hardware is (more) confused.
Don't use hard-coded values in the sanity check.
Don't use hard-coded values in the phy error and receive antenna
checks.
also remove the magic size value here for the transmit antenna statistics.
Change-Id: Ifebebef068d9abe7abfa61204dc900095bd6914c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3921
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
kernel_args_malloc should be used after heap_init, or it will failed
when we new some region instance.
Change-Id: I457057b1e0ff6d4def9e101485e38fec1848d8de
Signed-off-by: Han Pengfei <pengphei@qq.com>
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3912
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
iwn(4): (partially) rewrite A-MPDU Tx path
Generic Tx stats fixes:
- do not try to parse "aggregation status" for single frames; send them
to iwn_tx_done() instead;
- try to attach mbuf / node reference pair to reported BA events;
allows to fix reported status for ieee80211_tx_complete() and ifnet counters
(previously all A-MPDU frames were counted as failed - see PR 210211);
requires few more firmware bug workarounds;
- preserve short / long retry counters for wlan_amrr(4)
(disabled for now - causes significant performance degradation).
- Add new IWN_DEBUG_AMPDU debug category.
- Add one more check into iwn_tx_data() to prevent aggregation ring
overflow.
- Workaround 'seqno % 256' != 'current Tx slot' case (until D9195 is not
in the tree).
- Improve watchdog timer updates (previously watchdog check was omitted
when at least one frame was transmitted).
- Stop Tx when memory leak in currently used ring was detected (unlikely
to happen).
- Few other minor fixes.
Was previously tested with:
- Intel 6205, STA mode (Tx aggregation behaves much better now).
- Intel 4965AGN, STA mode (still unstable).
PR: 192641, 210211
Reviewed by: adrian, dhw
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D10728
iwn(4): drop return code from iwn_*attach functions (they cannot fail)
While here, add missing trace 'end' marker in iwn5000_attach().
MFC after: 1 week
iwn(4): drop i_seq field initialization for A-MPDU frames.
It is done by net80211 since r319460.
MFC after: 24 days
X-MFC-With: 343094
iwn(4): plug initialization path vs interrupt handler races
There are few places in interrupt handler where the driver
lock is dropped; ensure that device is still running before
processing remaining ring entries.
PR: 192641
MFC after: 5 days
iwn: Set default ampdu parameters.
These are from the linux iwlwifi driver ;the default use smaller
maximum AMPDUs (8k) and a much smaller density (none.) The latter
could cause stability issues.
Tested:
* Tested on Intel 6300, STA mode.
Differential Revision: https://reviews.freebsd.org/D25113
bwi: clean up empty lines in .c and .h files
mwl: clean up empty lines in .c and .h files
Fix ieee80211_radiotap(9) usage in wireless drivers:
- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.
- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.
Tested with Netgear WG111 v3 (urtw(4)), STA mode.
MFC after: 2 weeks
Change-Id: I7f194a3b78a058aa598634039cfab27e415a4894
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3917
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Add madmax
- Move rudolfc back to active contributors
- Add Shubham and Suhel to contributors, as former GSoC students and as
GSoC mentors
Change-Id: I2c4c1d4795e54158b837510b5a9832881ae80c21
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3909
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Once change 2342 is in place (running first boot scripts exported from
packages), see https://review.haiku-os.org/c/haiku/+/2342,
remove data/system/boot/post_install/add_catalog_entry_attributes.sh
and related support infrastructure (magic files, launch_roster entries).
The work this script did can in fact be done at image creation time
instead of at first boot.
Change-Id: I485e1a0a87c3e6a6ba3f882e65996f2327134d37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3751
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
fb3bc59600e25268ed5750fdc351b1e9423a8fb4 Restructure mbuf send tags to provide stronger guarantees.
2b60ecf197e0e187ac028d66d279805e6bece77b Don't use if_maddr_rlock() in 802.11, use epoch(9) directly
998bd62c311425c8cebb4506d7d4a3a9d5ff7f9e [net80211] Print out a bad PN in both hex and decimal.
8bc0d2b8553e012412d03468f84588dc34dea4c4 Fix !DEBUGNET build after r362138
tested with idualwifi7260, iprowifi4965 and atheroswifi
net80211: fix out-of-bounds read in ieee80211_amrr(9).
ieee80211_alloc_node() does not initialize rateset tables; that's not
expected by rate control modules and will result in array access at
index -1 - where ni_essid[] array is located (zeroed at allocation, so
there are no user-visible consequences).
Just delay rate control initialization to the moment, when rateset
tables are initiaziled; nothing will use rates here anyway.
MFC after: 4 days
net80211: fix duplicate sequence number bump for non-AMPDU QoS frames.
This should be a part of r312972.
MFC after: 4 days
net80211: fix panic when device is removed during initialization
if_dead() is called during device detach - check if interface is
still exists before trying to refresh vap MAC address
(IF_LLADDR will trigger page fault otherwise).
MFC after: 5 days
net80211: fix possible panic for some drivers after r342211
Check if rate control structures were allocated before trying to
access them in various places; this was possible before on
allocation failure (unlikely), but was revealed after r342211
where allocation was deferred.
In case if driver uses wlan_amrr(4) and it is loaded it
is possible to reproduce the panic via
sysctl net.wlan.<number>.rate_stats
(for wlan0 the number will be 0).
Tested with: RTL8188EE, AP mode + RTL8188CUS, STA mode.
MFC after: 3 days
net80211: provide rate validation for injected frames.
There may be various side effects (device timeout, firmware and / or
kernel panic) when an invalid (or inapplicable - e.g., an MCS rate
for 11g-only device) is set; check rates before sending the frame to
the driver.
How-to-reproduce:
Set an MCS (real or bogus - with 0x80 bit set) rate in ibp_rate0 field
for any device that uses ieee80211_isratevalid() for rate checks -
rum(4), run(4), ural(4), bwi(4) or ral(4); if kernel is compiled
with INVARIANTS the check will result in "rate %d is basic/mcs?" panic.
Tested with WUSB54GC (rum(4)), AP mode.
MFC after: 1 week
Print more WPS attributes in verbose "list scan" output
- Move WPS related defines to dedicated file
- Add handlers for more WPS attributes
PR: 217317
Submitted by: J.R. Oldroyd <fbsd@opal.com>
MFC after: 3 weeks
net80211: resolve ioctl <-> detach race for ieee80211com structure
Since r287197 ieee80211com is a part of drivers softc; as a result,
after detach all pointers to it (iv_ic, ni_ic) are invalid. Most
possible users (tasks, interrupt handlers) are blocked / removed
when device is stopped; however, ioctl handlers were not tracked
and may crash if ieee80211com structure is accessed.
Since ieee80211com pointer access from ieee80211vap structure is not
protected by lock (constant after interface creation) and used in
many other places just use reference counting for ioctl handlers;
on detach set 'detached' flag and wait until reference counter goes to 0.
For HEAD ieee80211vap size was changed (__FreeBSD_version bumped);
however, in stable branches I'm going to split / reuse the last
iv_spare field for KBI stability.
Tested with:
- rsu(4), SIOCSIFCAP (-rxcsum) ioctl;
- rtwn_pci(4), SIOCG80211 / IEEE80211_IOC_HTPROTMODE ioctl.
MFC after: 1 week
net80211: fix channel list construction for non-auto operating mode.
Change the way how channel list mode <-> desired mode match is done:
- Match channel list mode for next non-auto desired modes:
* 11b: 11g, 11ng, 11acg;
* 11a: 11na, 11ac
- Add pre-defined channels only when one of the next conditions met:
* the desired channel mode is 'auto' or
* the desired channel and selected channel list modes are exactly
the same or
* the previous rule (11g / 11n / 11ac promotion) applies.
Before r275875 construction work properly for all except
11ng / 11na / 11acg / 11ac modes - these were broken at all
(i.e., the scan list was empty); after r275875 all checks were removed,
so scan table was populated by all device-compatible channels
(desired mode was ignored).
For example, if I will set 'ifconfig wlan0 mode 11ng' for RTL8821AU:
- pre-r275875: nothing, scan will not work;
- after r275875: both 11ng and 11na bands were scanned; also, since 11b
channel list was used, 14th channel was scanned too.
- after this change: only 11ng - 1-13 channels - are used for scanning.
Tested with:
* RTL8188EE, STA mode.
* RTL8821AU, STA mode.
MFC after: 5 days
net80211: turn channel mode check into assertion.
There is may be only 11b channel (since chanflags[] table
maps MODE_AUTO to the corresponding 11b channel flags).
Checked with RTL8812AU, STA mode.
MFC after: 5 days
net80211: reuse TICKS_2_MSEC / MSEC_2_TICKS macros from sys/time.h
Replace in-place implementation with system-wide one; since it
guarantees non-zero result drop all less-than-one checks from
drivers and net80211.
MFC after: 2 weeks
Remove 2GHz channel list copies from wireless drivers.
Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.
Checked with RTL8188EE, country US / JP / KR / UA.
MFC after: 2 weeks
Do not acquire IEEE80211_LOCK twice in cac_timeout(); reuse locked function instead.
It is externally visible since r257065.
MFC after: 5 days
net80211(4): do not setup roaming parameters for unsupported modes.
ifconfig(8) prints per-mode parameters if they are non-zero; since
we have 13 possible modes with 3...5 typically supported this change
should greatly reduce amount of information for 'ifconfig <wlan> list roam'
command.
While here ensure that sta_roam_check() will not use roaming parameters
for unsupported modes (it should not).
This change effectively reverts r188776.
MFC after: 2 weeks
net80211(4): fix rate check when 'roaming' ifconfig(8) option is set to 'auto'
Do not try to clear 'basic rate' bit from roamRate; it cannot be here and,
actually, this operation clears 'MCS rate' bit instead, breaking comparison
for 11n / 11ac modes.
Tested with RTL8188CUS, HOSTAP mode + RTL8821AU, STA mode.
MFC after: 3 days
net80211(4): do not setup Tx parameters for unsupported modes.
That should shorten 'ifconfig <wlan> list txparam' output since
unsupported modes will not be shown.
Checked with RTL8188EE, STA mode.
MFC after: 2 weeks
net80211(4): validate supplied roam:rate values from ifconfig(8)
MFC after: 4 days
net80211(4): hide casts for 'i_seq' field offset calculation inside ieee80211_getqos() and reuse it in various places.
Checked with RTL8188EE, HOSTAP mode + RTL8188CUS, STA mode.
MFC after: 2 weeks
Build fix for Haiku
net80211: correct check for SMPS node flags updates
Update node flags when driver supports SMPS, not when it is disabled or
in dynamic mode ((iv_htcaps & HTCAP_SMPS) != 0).
Checked with RTL8188EE (1T1R), STA mode - 'smps' word should disappear
from 'ifconfig wlan0' output.
MFC after: 2 weeks
Enhance the comment ieee80211_add_channel() to avoid a misunderstanding that the function does not work additive when repeatedly called for diffferent bands.
Reviewed by: avos (a few months ago)
MFC after: 2 weeks
net80211: Move rate printing in amrr_node_stats() to a separate method
This makes amrr_node_stats() cleaner and allows the rate printing to be
reusable.
Submitted by: Neel Chauhan <neel at neelc.org>
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D22318
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all low hanging fruits as MPSAFE.
Reviewed by: markj
Approved by: kib (mentor, blanket)
Differential Revision: https://reviews.freebsd.org/D23626
Haiku: added CTLFLAG_NEEDGIANT
Fix -Wvoid-pointer-to-enum-cast warnings.
This pattern is used in callbacks with void * data arguments and seems
both relatively uncommon and relatively harmless. Silence the warning
by casting through uintptr_t.
This warning is on by default in Clang 11.
Reviewed by: arichardson
Obtained from: CheriBSD (partial)
MFC after: 1 week
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24425
Don't indirect user pointers directly in two 802.11s ioctls.
IEEE80211_MESH_RTCMD_ADD was invoking memcmp() to validate the
supplied address directly on the user pointer rather than first doing
a copyin() and validating the copied value.
IEEE80211_MESH_RTCMD_DELETE was passing the user pointer directly to
ieee80211_mesh_rt_del() rather than copying the user buffer into a
temporary kernel buffer.
Reviewed by: brooks, kib
Obtained from: CheriBSD
MFC after: 2 weeks
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24562
Use the unicast key when transmitting DWDS AP multicast frames.
I'm still not sure whether this is the full solution, but here goes.
I have a two node DWDS setup - a main AP with the ethernet bridge uplink
and a satellite AP in the back of the house. They're both AR9344+AR9580
dual band 11n APs.
The problem was that multicast frames was not going from the DWDS AP to
the DWDS STA. Unicast frames are fine, and multicast frames from the
DWDS STA to AP are fine.
Now, multicast and unicast frames from the STA -> AP are just transmitted
using the unicast key. That's fine. However, the AP -> STA multicast
frames by default are transmitted using the current default / multicast
key, the shared one between all STAs in a BSS. Now, the DWDS implementation
ignores non WDS frames - it only allows about 4 address frames outside
of management / EAPOL frames! - so the STA side ignores the normal multicast
frames.
Instead, the AP side uses ieee80211_dwds_mcast() to send multicast frames
to each WDS VAP that was created as part of the "dynamic" part of DWDS.
This should be queuing them individually to each node instead of using
the normal multicast send path; and this is how they should get turned into
4-addr WDS frames.
HOWEVER, ieee80211_encap() was trying to use the default TX key to queue
them rather than the unicast key that's already setup. Since this synthetic
node doesn't have the default TX key setup, transmission fails. Things
would be fine in WEP and in open mode because in both cases you would
have static keys (or no keys) setup. It just fails in WPA mode.
This resolves the issue. AP DWDS multicast is now sent using the unicast
key just like in STA mode and I'm pretty sure the STA mode side will stil
work fine (as it's a STA VAP with a DWDS flag..)
Tested:
* TL-WDR3600/4300 APs
net80211: post RTM_IFINFO notification after toggling IFF_DRV_RUNNING
This is useful when a wireless driver is stopped or started in response
to events like an RF Kill button press. Applications like
wpa_supplicant depend on such events to have a correct view of interface
state.
Reviewed by: adrian, cy, melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24925
Fix interrupted scan logic and ticks comparison
The scan task refactoring stuff circa 2014-2016 broke the blocking task
into a taskqueue with some async bits, but it apparently broke scans
being interrupted by traffic.
Notably - the new "field" SCAN_PAUSE sets both SCAN_INTERRUPT and SCAN_CANCEL,
and a bunch of existing code was checking for SCAN_CANCEL only and breaking
the scan. Unfortunately it was then (a) cancelling the scan entirely and
(b) not notifying userland that scan was done.
So:
* Update the calls to scan_end() to only pass in 1 (saying the scan is complete)
if SCAN_CANCEL is set WITHOUT SCAN_INTERRUPT. If both are set then yes,
the scan is interrupted, but it isn't canceled - it's just paused.
* Update the "did the scan flags change whilst the driver was called" logic
to check for canceled scans, not interrupted scans.
* The "scan done" logic now explicitly checks for either interrupted or
completed scans. This accounts for the situation where a scan is being
aborted via traffic but it ALSO happens to have finished (ie the last
channel was checked.)
This doesn't ENTIRELY fix scanning as the resume function is broken
due to incorrect ticks math. Thus, the second half of this patch
changes the ieee80211_ticks_*() macros to use int instead of long,
matching the logic that the TCP code does with ticks and handles
wrapping / negative ticks values. If cast to long then the wrapping
math wouldn't work right (ie, if ticks was actually negative,
ie, after the system has been up for a while.)
This allows contbgscan() to correctly calculate if a scan should
continue based on ticks and ic->ic_lastdata .
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D25031
Send a probe request after IBSS node discovery
This sends a probe request after IBSS node discovery through
beacon frames. This allows things like HT and VHT capabilities
to be "negotiated" in adhoc mode.
It is .. kinda fire and pray - this isn't retried after discovery
so it's quite possible that nodes occasionally don't come up with
HT/VHT rate upgrades. At some point it may be a fun side project
to add support for retrying these probe requests/negotiations
after IBSS node discovery.
Tested:
* tested with multiple ath(4) NICs in 11n mode.
Differential Revision: https://reviews.freebsd.org/D24979
Add some more debugging during scanning
I'm trying to chase down more weird "I am not doing an incremental scan
when being asked" issues so these debugging statements help.
Notably, I've added more debugging around reasons why the scan is skipped -
eg because the cache is considered hot.
This should be a no-op unless you care about the debugging output!
Add field definition for A-MSDU inside A-MPDU.
Now that I have A-MSDU and A-MPDU coexisting together, we need to actually
announce if (a) it's permitted and (b) figure out if we should use it
when transmitting.
This just adds the field; it doesn't yet include it in ADDBA exchanges.
Add some TODOs around A-MSDU in A-MPDU negotiation.
net80211 currently doesn't negotiate A-MSDU in A-MPDU during ADDBA.
I've added the field in net80211 and this commit:
* Prints out the ADDBA field value during ADDBA;
* Adds some comments around where I need to follow up with some
negotiation logic.
Right now we don't have a driver flag anywhere which controls
whether A-MSDU in A-MPDU is allowed. I know it works (I have it
manually turned on at home on a couple test APs, heh!) but
I can't flip it on until we can negotiate it.
Tested:
* AR9380, STA/AP mode, printing out ADDBA requests
Migrate short slot time configuration into per-vap and deferred taskqueue updates.
The 11b/11g ERP and slot time update handling are two things which weren't
migrated into the per-VAP state when Sam did the initial VAP work.
That makes sense for a lot of setups where net80211 is driving radio state
and the radio only cares about the shared state.
However, as noted by a now deleted comment, the ERP and slot time updates
aren't EXACTLY correct/accurate - they only take into account the most
RECENTLY created VAP, and the state updates when one creates/destroys
VAPs isn't exactly great.
So:
* track the short slot logic per VAP;
* whenever the slot time configuration changes, just push it into a deferred
task queue update so drivers don't have to serialise it themselves;
* if a driver registers a per-VAP slot time handler then it'll just get the
per VAP one;
* .. if a driver registers a global one then the legacy behaviour is maintained -
a single slot time is calculated and pushed out.
Note that the calculated slot time is better than the existing logic - if ANY
of the VAPs require long slot then it's disabled for all VAPs rather than
whatever the last configured VAP did.
Now, this isn't entirely complete - the rest of ERP tracking around short/long
slot capable station tracking needs to be converted into per-VAP, as well
as the preamble/barker flags. Luckily those also can be done in a similar
fashion - keep per-VAP counters/flags and unify them before doing the driver
update. I'll defer that work until later.
All the existing drivers can keep doing what they're doing with the global
slot time flags as that is maintained. One driver (iwi) used the per-VAP
flags instead of the ic flags, so now that driver will work properly.
This unblocks some ath10k porting work as the firmware takes the slot time
configuration per-VAP rather than globally, and some firmware handles
STA+AP and STA+STA (on same/different channels) configurations where
the firmware will switch slot time as appropriate.
Tested:
* AR9380, STA/AP mode
* AR9880 (ath10k), STA mode
Add initial A-MSDU in A-MPDU negotation support.
This is hopefully a big no-op unless you're running some extra
patches to flip on A-MSDU options in a driver.
802.11n supports sending A-MSDU in A-MPDU. That lets you do things
like pack small frames into an A-MSDU and stuff /those/ into an A-MPDU.
It allows for much more efficient airtime because you're not
wasting time sending small frames - which is still a problem when
doing A-MPDU as there's still per-frame overhead and minimum A-MPDU
density requirements.
It, however, is optional for 802.11n. A lot of stuff doesn't advertise
it (but does it, just wait!); and I know that ath10k does it and my
ath(4) driver work supports it.
Now, 802.11ac makes A-MSDU in A-MPDU something that can happen more
frequently, because even though you can send very large A-MPDUs
(like 1 megabyte and larger) you still have the small frame problem.
So, 802.11ac NICs like ath10k and iwm will support A-MSDU in A-MPDU
out of the box if it's enabled - and you can negotiate it.
So, let's lay down the ground work to enable A-MSDU in A-MPDU.
This will allow hardware like iwn(4) and ath(4) which supports
software A-MSDU but hardware A-MPDU to be more efficient.
Drivers that support A-MSDU in A-MPDU will set TX/RX htcap flags.
Note this is separate from the software A-MSDU encap path; /that/
dictates whether net80211 is doing A-MSDU encapsulation or not.
These HTC flags control negotiation, NOT encapsulation.
Once this negotiation and driver bits are done, hardware like
rtwn(4), run(4), and others will be able to use A-MSDU even without
A-MPDU working; right now FF and A-MSDU aren't even attempted
if you're an 11n node. It's a small hold-over from the initial
A-MPDU work and I know how to fix it, but to flip it on properly
I need to be able to negotiate or ignore A-MSDU in A-MPDU.
Oh and the fun part - some 11ac APs I've tested will quite happily
decap A-MSDU in A-MPDU even though they don't negotiate it when
doing 802.11n. So hey, I know it works - I just want to properly
handle things. :-)
Tested:
* AR9380, STA/AP mode
print out node A-MSDU state.
Now that the node AMSDU TX/RX flags are correctly set in ieee80211_ht.c,
we can print out the AMSDU state here.
Don't call ic_updateslot if it's not set.
Turns out this isn't a required call. I didn't pick it up because my
uncommitted changes involve new updateslot methods for cards I'm working
on.
Dunce hat to: adrian
Fix typo.
Oops!
Fix this typo!
I've just started using this macro in upcoming amsdu/ampdu/ff rework and
yes, too many parens. Oops!
Flip on A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames options.
This updates the logic to allow:
* A-MPDU if available;
* A-MSDU if available and A-MPDU is off/NACKed;
* A-MPDU+A-MSDU if it's available and negotiated;
* Fast frames if the node is 11abg (and not HT/VHT.)
This allows for things to fail back to A-MSDU or fast frames
if A-MPDU isn't available rather than needing to be non-HT/non-VHT.
It also allows A-MPDU+A-MSDU to work if it's negotiated.
Tested:
* AR9380, STA + AP mode (A-MPDU, A-MSDU, FF, A-MPDU+A-MSDU)
* RT5350, STA mode (A-MSDU, FF)
* AR9170, STA mode (A-MSDU, FF)
Add a method to return the vap's ifname.
This removes the requirement to know what's in the ifp.
(If someone wants a quick clean-up task, it'd be nice to convert instances
of ifp dereferencing for if_xname over to this method.)
ok ok if_xname won't ever be NULL.
Somewhere in net80211 if_xname is checked against NULL but it doesn't trigger
a compiler warning, but this does. So DTRT for FreeBSD and the other if_xname
derefences can be converted to this function at a later time.
First part of A-MSDU offload handling - don't bump A-MPDU reordering seqno
When doing A-MSDU offload handling the driver is required to mark
A-MSDUs from the same MPDU with the same sequence number.
It then tags them as AMSDU (if it's a decap'ed A-MSDU) and AMSDU_MORE
(saying there's more AMSDUs decapped in the same MSDU.)
This allows encryption and sequence number offload to work right.
In the A-MSDU path the sequence number check looks at the A-MSDU flags
in the frame to see whether it's part of the same seqno and will pass them
(ie, not increment rx_seq until the last A-MSDU is seen from the driver,
or a new seqno shows up.0
However, I did this work in the A-MSDU path but not the A-MSDU in A-MPDU path.
For the non A-MDSU offload case the A-MPDU receive reordering will do its
thing and then pass up the MPDU up for decap - which then will see it's
an A-MSDU and decap each sub-frame. But this isn't done for offloaded
A-MSDU frames.
This requires two parts:
* Don't bump the RX sequence number, same as above; and
* If frames go into the reordering buffer, they need to be added into the slot
as a set of frames rather than a single frame, so once a new seqno shows up
this slot can be marked as "full" and we can move on.
This patch does the first. The latter requires that I find and commit
work to change rxa_m from an mbuf to an mbufq and the nhandle A-MSDU
there. But, the first is enough to allow the normal case (ie, no or not
a lot of A-MPDU RX reordering) to work.
This allows the athp driver (QCA9880) throughput to go from VERY low
(like 5mbit TCP, 1/3-1/4 expected UDP throughput) to ~ 250mbit TCP
and > 300mbit UDP on a VHT/40 channel. TCP sucks because, well, it
shows up as MASSIVE packet loss when all but one frame in a decap'ed
A-MSDU stream is dropped. Le whoops.
Now, where'd I put that laptop with the patch for rxa_m mbufq that
I wrote like in 2017...
Tested:
* AR9380, STA/AP mode (a big no-op, no A-MSDU hardware decap);
* if_run (RT3593), STA DWDS mode (A-MPDU / A-MSDU receive, but again
no A-MSDU hardware decap);
* QCA9880, STA/AP mode (which is doing hardware A-MPDU/A-MSDU decap,
but no A-MPDU reordering in the firmware.)
net80211: Add framework for debugnet(4) support
Allow net80211 drivers to register a small vtable of debugnet-related
methods.
This is not a functional change. Driver support is needed, similar to
debugnet(4) for wired NICs.
Reviewed by: adrian, markj (earlier version both)
Differential Revision: https://reviews.freebsd.org/D17308
separate out node allocation and node initialisation.
This is a new, optional (for now!) method that drivers can use to separate
node allocation and node initialisation. Right now they're the same, and
drivers that need to do node allocation via firmware commands need to sleep
and thus they need to defer node allocation into an internal taskqueue.
Right now they're just separate but not deferred. Later on if I get the time
we'll start deferring the node and key related operations but that requires
making a bunch of other stuff (notably things that generate frames!) also
async/deferred.
Tested:
* RT3593, STA/DWDS mode
* AR9380, STA/AP modes
* QCA9880 (athp) - STA/AP modes
Handle offloaded AMSDU in AMPDU reordering.
In the 11n world, most NICs did A-MPDU receive/transmit offloading but
not A-MSDU offloading. So, the net80211 A-MPDU receive path would just
receive MPDUs, do the reordering bit, pass it up to the rest of
net80211 for crypto decap and then do A-MSDU decap before throwing ethernet
frames up to the rest of the system.
However 11ac and 11ax NICs are increasingly doing A-MSDU offload (and
newer 11ax stuff does socket offload, but hey I don't want to scare people
JUST yet) - so although A-MPDU reordering may be done in the OS, A-MSDUs
look like a normal MPDU. This means that all the MSDUs are actually
faked into a set of MPDUs with matching 802.11 header - the sequence number,
QoS header and any encryption verification bits (like IV) are just copied.
This shows up as MASSIVE packet loss in net80211, cause after the first MPDU
we just toss the rest.
(And don't get me started about ethernet decap with A-MPDU host reordering;
we'll have to cross that bridge for later 11ac and 11ax bits too.)
Anyway, this work changes each A-MPDU reorder slot into an mbufq.
The mbufq is treated as a whole set of frames to pass up to the stack
and reordered/de-duped as a group. The last frame in the reorder list
is checked to see if it's an A-MSDU final frame so any duplicates are
correctly tossed rather than double-received. Other than that, the
rest of the logic is unchanged.
The previous commit did a small subset of this - if there wasn't any reordering
going on then it'd accept the A-MSDUs. This is the rest of the needed work.
This is a no-op for 11n NICs doing A-MPDU reordering but needing software
A-MSDU decap - they aren't tagged as A-MSDU and so any subsequent
frames added to the reorder slot are tossed.
Tested:
* QCA9880 (ath10k/athp) - STA/AP mode;
* RT3593 (if_rsu) - 11n STA+DWDS mode (I'm committing through it rn);
* QCA9380 (if_ath) - STA/AP mode.
Also convert the ddb path
Whoops - this belonged in my previous commit.
add a concat method.
Reviewed by: gnn, ae, glebius
Approved by: ae, glebius
Differential Revision: https://reviews.freebsd.org/D10158
Treat frames without an rx status as not a decap'ed A-MSDU.
Drivers for NICs which do A-MSDU decap in hardware / driver will need to
set the rx status, so if it's missing then treat it as not a decap'ed
A-MSDU.
Add initial U-APSD negotiation support.
U-APSD (unscheduled automatic power save delivery) is a power save method
that's a bit better than legacy PS-POLL - stations can mark frames with
an extra flag that tells the AP to leak out more frames after it sends
its own frames rather than needing to send a PS-POLL to get another frame
from the AP.
Now, this code just handles the negotiation bits; it doesn't actually
implement U-APSD. That's up to drivers, and nothing in the tree yet
implements this. I /may/ implement this for ath(4) if I eventually care
enough but right now I plan on just implementing it for firmware offload
based NICs that handle this in the NIC.
I'll commit the ifconfig bit after this and I may have some follow-up
commits as this gets used more by me in local testing.
This should be a glorious no-op for everyone else. If things change
for anyone that isn't fixed by a complete recompile then please reach out
to me.
Add missing commit to previous-1 uapsd commit.
Whoops; somehow my big commit line didn't include this.. cue the tree breakage emails.
Migrate HT/legacy protection mode and preamble calculation to per-VAP flags
The later firmware devices (including iwn!) support multiple configuration
contexts for a lot of things, leaving it up to the firmware to decide
which channel and vap is active. This allows for things like off-channel
p2p sta/ap operation and other weird things.
However, net80211 is still focused on a "net80211 drives all" when it comes to driving
the NIC, and as part of this history a lot of these options are global and not per-VAP.
This is fine when net80211 drives things and all VAPs share a single channel - these
parameters importantly really reflect the state of the channel! - but it will increasingly
be not fine when we start supporting more weird configurations and more recent NICs.
Yeah, recent like iwn/iwm.
Anyway - so, migrate all of the HT protection, legacy protection and preamble
stuff to be per-VAP. The global flags are still there; they're now calculated
in a deferred taskqueue that mirrors the old behaviour. Firmware based drivers
which have per-VAP configuration of these parameters can now just listen to the
per-VAP options.
What do I mean by per-channel? Well, the above configuration parameters really
are about interoperation with other devices on the same channel. Eg, HT protection
mode will flip to legacy/mixed if it hears ANY BSS that supports non-HT stations or
indicates it has non-HT stations associated. So, these flags really should be
per-channel rather than per-VAP, and then for things like "do i need short preamble
or long preamble?" turn into a "do I need it for this current operating channel".
Then any VAP using it can query the channel that it's on, reflecting the real
required state.
This patch does none of the above paragraph just yet.
I'm also cheating a bit - I'm currently not using separate taskqueues for
the beacon updates and the per-VAP configuration updates. I can always further
split it later if I need to but I didn't think it was SUPER important here.
So:
* Create vap taskqueue entries for ERP/protection, HT protection and short/long
preamble;
* Migrate the HT station count, short/long slot station count, etc - into per-VAP
variables rather than global;
* Fix a bug with my WME work from a while ago which made it per-VAP - do the WME
beacon update /after/ the WME update taskqueue runs, not before;
* Any time the HT protmode configuration changes or the ERP protection mode
config changes - schedule the task, which will call the driver without the
net80211 lock held and all correctly serialised;
* Use the global flags for beacon IEs and VAP flags for probe responses and
other IE situations.
The primary consumer of this is ath10k. iwn could use it when sending RXON,
but we don't support IBSS or AP modes on it yet, and I'm not yet sure whether
it's required in STA mode (ie whether the firmware parses beacons to change
protection mode or whether we need to.)
Tested:
* AR9280, STA/AP
* AR9380, DWDS STA+STA/AP
* ath10k work, STA/AP
* Intel 6235, STA
* Various rtwn / run NICs, DWDS STA and STA configurations
Commit files missing in the previous commit
These belong to my previous commit, but apparently I typed ieee80211_vhf.[ch]
and forgot ht.h. Le oops.
80211: consistently spell 80P80
The standard uses 80+80 and 80p80 but nowhere 80_80.
Switch the latter to 80P80 for all the macros and comments refering
to #defined flags which I could find.
The only place we leave as 80p80 is the ifconfig command line arguments
as we spell them all in lower case.
Ideally we would use 80+80 for any interactions with the user and
80P80 for anything internal but let us not confuse parsers and
hence avoid the '+' in either case.
Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26001
80211: consistently order 160 and 80+80
For flags and checks the order goes VHT160 and then VHT80P80 unless
checks are in reverse order ("more comes first") in which case we
deal with VHT80P80 first.
The one reverse order to pick out is where we check channel
prefernences. While it may seem that VHT160 is better, finding
two "free" channels (VHT 80+80) is more likely so we do prefer that.
While dealing with VHT160 and VHT80P80 add extra clauses previously
missing or marked TODO in a few places.
Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26002
net80211: remove vertical whitespace
No functional changes.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
net80211/ifconfig: print hardware device name for wlan interfaces
Add IEEE80211_IOC_IC_NAME to query the ic_name field and in ifconfig
to print the parent interface again. This functionality was lost
around r287197. It helps in case of multiple wlan interfaces and
multiple underlying hardware devices to keep track which wlan
interface belongs to which physical device.
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Reviewed by: adrian, Idwer Vollering
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25832
net80211 / ifconfig: cleanup the use of IEEE80211_FVHT_USEVHT*
Rather then using magic numbers duplicate IEEE80211_FVHT_VHT* in
ifconfig (cleanup of these and other flags used and not exposed by
net80211 should happen later) and use those.
In the kernel this simplifies one ioctl path (the other one currently
relies on individual bit flags being passed in).
We also re-order the 80P80 and 160 flag for 160 to come before 80+80
and more clearly leave the flags as TODO in one of the 160/80+80 cases.
Reviewed by: adrian
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26000
net80211: return 80P80 before 160
In ieee80211_vht_get_chwidth_ie() we need to return 80P80 (3) before
VHT160 (2) as otherwise we'll never use 80P80. Fix the order.
MFC after: 2 weeks
X-MFC with: r364303 (which missed this)
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
net80211: VHT correct NSS Set loop boundary
For the <VHT-MCS, NSS> tuple, NSS is 1..8 (or in our loop case 0..7
but not 0..6). Correct the boundry to check for < 8 and not < 7.
MFC after: 2 weeks
Reviewed by: adrian
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26087
net80211: replace magic number by define
Rather than coding an array size of [4] replace the number with
WME_NUM_AC.
MFC after: 2 weeks
Reviewed by: adrian
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26090
net80211: set_vht_extchan() reverse order to always return best
In set_vht_extchan() the checks are performed in the order of VHT20/40/80.
That means if a channel has a lower and higheer VHT flag set we would
return the lower first.
We normally do not set more than one VHT flag so this change is supposed
to be a NOP but follows the logical thinking order of returning the best
first. Also we nowhere assert a single VHT flag so make sure we'll not
be stuck with VHT20 when we could do more.
While here add the debugging printfs for VHT160 and VHT80P80 which still
need doing once we deal with a driver at that level.
Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26088
net80211: improve media information for VHT5GHZ
Improve ieee80211_media_setup(), media2mode(), and
ieee80211_rate2media() for VHT5GHZ at least.
Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26089
net80211: enhance getflags*() and ieee80211_add_channel*()
For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.
Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.
Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.
Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.
ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.
Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.
MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091
net: clean up empty lines in .c and .h files
Provide MS() and SM() macros for 80211 and wireless drivers.
We have (two versions) of MS() and SM() macros which we use throughout
the wireless code. Change all but three places (ath_hal, rtwn, and rsu)
to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK()
macros. Also change one internal case using both _S and _M instead of
just _S away from _M (one of the reasons rtwn and rsu were not changed).
This was done semi-mechanically. No functional changes intended.
Requested by: gnn (D26091)
Reviewed by: adrian (pre line wrap)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26539
80211: non-functional changes
Sort a few VHT160 and 80+80 lines, update some comments, and remove
a superfluous ','.
No functional changes intended.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
net80211: whitespace
Fix indentation for the multi-line copies of
ieee80211_add_channel_list_5ghz() for the 3 bands.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
net80211: update for (more) VHT160 support
Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ()
and its 80+80 counter part to check in vhtcaps for appropriate
levels of support and use the macros throughout the code.
Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue
to vht80 in various parts of the code.
Add ieee80211_add_channel_cbw() which also takes the CBW flag
fields and make the former ieee80211_add_channel() a wrapper to it.
With the CBW flags we can add HT/VHT channels passing them to
getflags() for the 2/5ghz functions.
In ifconfig(8) add the regdomain_addchans() support for VHT160
and VHT80P80.
With this (+ regdoain.xml updates) VHT160 channels can be
configured, listed, and pass regdomain where appropriate.
Tested with: iwlwifi
Reviewed by: adrian
MFC after: 10 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26712
net80211: fix a typo
Correct a typo referring to the wrong flags in a comment.
No functional changes.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Add new privileges; restrict what can be done in a jail.
Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP.
+ VAP_MANAGE is everything but setting the MAC and creating a VAP.
+ VAP_SETMAC is setting the MAC address of the VAP.
Typically you wouldn't want the jail to be able to modify this.
+ CREATE_VAP is to create a new VAP. Again, you don't want to be doing
this in a jail, but this DOES stop being able to run some corner
cases like Dynamic WDS (DWDS) AP in a jail/vnet. We can figure this
bit out later.
This allows me to run wpa_supplicant in a jail after transferring
a STA VAP into it. I unfortunately can't currently set the wlan
debugging inside the jail; that would be super useful!
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D25630
net80211: factor out the priv(9) checks into OS specifc code.
Factor out the priv(9) checks into OS specifc code so other OSes can equally
implement them. This sorts out those XXX in the net80211 code.
We provide 3 arguments (cmd, vap, ifp) where available to the functions, in
order to allow other OSes to use that data but also in case we'd add auditing
to these check to have the information available. For now the arguments are
marked __unused.
PR: 249403
Reported by: martin(NetBSD)
Reviewed by: adrian, martin(NetBSD)
MFC after: 10 days
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26541
sockio.h: add missing ioctl SIOCSIFLLADDR
Change-Id: I68703723ac919b901adb99ca1f7d0319fd0271f5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3910
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Switch to Python3
- Switch to mawk instead of gawk
- Update ffmpeg (there are several new dependencies)
- Update ICU
- Fix various pre-existing problems with packages not being properly
declared for gcc2 (but somehow it ended up working)
- remove curl, subversion, mercurial
Confirmed that both nightly and release images are building fine on both
32 and 64bit. However, non-x86 architecture may require re-bootstrapping
to do a complete nightly or release image build (the minimal profile
should be fine)
Fixes #16751.
Change-Id: Iacac92923c4113b3e0a49a64b0b4cc1b8e2f5e2e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3871
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* kMaxOptionSize: TCP header size is 60 bytes. process_options() would have
accepted a longer header as permitted. add_options() would have possibly added
more options or SACK entries as permitted.
* tcp_segment: reserve memory for sack entries.
* _SendQueued(): "fLastAcknowledgeSent <= fReceiveNext": also send SACK entries
for received data when acknowledging a missing segment.
* _SendQueue(): after acknowledging, cancel the delayed acknowledgment timer.
* _Receive(): if calling Acknowledged() already triggered sending a segment
including an acknowledgement (piggy-back), remove "immediate acknowledge"
from the action. This helps to reduce empty ACKs for bidirectional streams.
Change-Id: I32808fbe549be0f5b25bcf4be17cd91a640b8ec4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3906
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
tested on Wireless 8265 / 8275 [8086:24fd]
iwm: improve rfkill handling
Previously the driver handled the bit within itself, but did not expose
the state change to net80211 and interface layers.
This change uses net80211 KPI for rfkill signaling.
The code is modeled after similar code in iwn and wpi.
Reviewed by: adrian
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24923
WiFi: fix ieee80211_media_change() callers
In r178354 with the introduction of multi-bss ("vap") support factoring
out started and with r193340 ieee80211_media_change() no longer returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should not
be called directly but is registered with ieee80211_vap_attach() instead.
Some drivers have not been fully converted. After fixing the return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra
function, where possible as well.
PR: 248955
Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
iwm: fix regression from r365419 (ieee80211_media_change())
In r365419 ieee80211_media_change() callers were updated to not longer
act on the obselete ENETRESET return code.
While in the old days iwm has done a stop/init cycle in these cases,
this was not executed since r193340.
As a consequence simplify iwm code as well by passing ieee80211_media_change()
right to ieee80211_vap_attach() as there is no more need for a local
implementation.
Reported by: Tomoaki AOKI (junchoon dec.sakura.ne.jp)
Tested by: Tomoaki AOKI (junchoon dec.sakura.ne.jp)
MFC after: 3 days
X-MFC: fix is already in stable/12
PR: 248955
iwm(4): Add support for Intel Killer(R) Wireless-AC 1550i
PR: 252578
Submitted by: shu <ankohuu@outlook.com>
MFC after: 1 week
Change-Id: Ibf9ec28986769bc7532e4c06ea2acafce7a8d86b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3907
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fix multiple definitions of 'terminaltype' and 'line' when linking.
Pointed out by gcc11.
Change-Id: I85552e2d243bd5db5f80806d92e6fa87bc41eb44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3903
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Since nv_globals.h and globals.h are included from several files,
it cause multiple definitions error when linking.
Pointed out by gcc11.
Change-Id: I10e27af062c6f4b49fdb9ef6bb3ba77809ebcba0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3904
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Initial rect size doesn't persist to changing text rect sizes and
alignment changes but insets do. Maintains a 3px border around text
on all sides.
Change-Id: I70e855c3b6b17bc576fd5e38cd43fedb6c830aef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3901
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-05-09 10:35:24 +00:00
6731 changed files with 145195 additions and 293519 deletions
Enable query support BFS_Initialize_Parameter Актывізаваць падтрымку запытаў
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter Адключэнне падтрымкі запытаў можа паскорыць некаторыя аперацыі файлавай\nсістэмы, але абмяжоўвае магчымасці пошуку на гэтым падзеле ў будучыні.\nНа падзелах, з якіх плануецца загрузка Haiku, неабходна мець падтрымку запытаў актыўнай.
Name: BFS_Initialize_Parameter Імя:
8192 (Mostly large files) BFS_Initialize_Parameter 8192 (Пераважна для велькіх файлаў)
Enable query support BFS_Initialize_Parameter Zapnout podporu dotazování
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter Zakázání podpory dotazů může urychlit určité operace se souborovým systémem, ale mělo by\nbýt použito pouze v případě, že je zcela jistě nepotřebujete.\nKaždý svazek, který je určen ke spouštění Haiku, musí mít podporu dotazů povolenu.
Name: BFS_Initialize_Parameter Jméno svazku:
8192 (Mostly large files) BFS_Initialize_Parameter 8192 (Hlavně velké soubory)
Enable query support BFS_Initialize_Parameter Permitir consultas
Enable query support BFS_Initialize_Parameter Activar soporte de consultas
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter Deshabilitar el soporte para consultas puede acelerar ciertas operaciones del sistema de archivos,\npero solo debe usarse si está absolutamente seguro que no necesitará realizar búsquedas de archivos.\nCualquier volumen que desee ser usado para iniciar Haiku debe tener habilitado el soporte para consultas.
Name: BFS_Initialize_Parameter Nombre:
8192 (Mostly large files) BFS_Initialize_Parameter 8192 (mayormente archivos grandes)
Enable query support BFS_Initialize_Parameter クエリを有効にする
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter クエリを無効にすると、ファイルシステム動作の一部が早くなりますが、\n絶対にそれを必要としないと確信している場合のみに使用するべきです。\nHaiku の起動を目的とするボリュームは、クエリを有効にする必要があります。
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter クエリを無効にすると、ファイルシステム動作の一部が早くなりますが、\n絶対にそれを必要としないと確信している場合のみに使用するべきです。\nHaiku の起動ボリュームは、クエリを有効にする必要があります。
Name: BFS_Initialize_Parameter ボリューム名:
8192 (Mostly large files) BFS_Initialize_Parameter 8192 (主に大きいファイル用)
Enable query support BFS_Initialize_Parameter Habilitar suporte a consultas
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter Desabilitar o suporte a consulta pode aumentar a velocidade de certas operações do sistema de arquivos, mas deveria\nser usado somente se estiver absolutamente certo que não irá precisar de consultas.\nQualquer volume que estiver designado para inicializar o Haiku deve ter suporte a consulta habilitado.
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter Desativar o suporte a consultas pode acelerar certas operações do sistema de arquivos, mas\nsó deve ser usado se houver certeza absoluta de que não será necessário fazer consultas.\nQualquer volume destinado a inicializar o Haiku deve ter o suporte a consultas habilitado.
Name: BFS_Initialize_Parameter Nome:
8192 (Mostly large files) BFS_Initialize_Parameter 8192 (Majoritariamente arquivos grandes)
Enable query support BFS_Initialize_Parameter Activează suportul de interogare
Disabling query support may speed up certain file system operations, but should\nonly be used if one is absolutely certain that one will not need queries.\nAny volume that is intended for booting Haiku must have query support enabled. BFS_Initialize_Parameter Dezactivarea suportului de interogare poate accelera anumite operații ale sistemului de fișiere, dar ar trebui\nsă fie utilizat doar dacă sunteți absolut sigur că nu veți avea nevoie de interogări.\nOrice volum care este destinat pentru pornirea Haiku trebuie să aibă suportul de interogare activat.
Name: BFS_Initialize_Parameter Nume:
8192 (Mostly large files) BFS_Initialize_Parameter 8192 (În general fișiere mari)
If the application will not quit you may have to kill it. Team monitor Калі праграма не спыніцца вам магчыма прыдзецца знішчыць яе.
Quit application Team monitor Спыніць праграму
Open Terminal Team monitor Адчыніць Тэрмінал
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Трымайце CONTROL+ALT+DELETE # секунду каб перазагрузіць.}other{Трымайце CONTROL+ALT+DELETE # секунд каб перазагрузіць.}}
Restart the desktop Team monitor Перазапусціць дэсктоп
If the application will not quit you may have to kill it. Team monitor Pokud se aplikace neukončí, možná ji budete muset zabít.
Quit application Team monitor Ukončit aplikaci
Open Terminal Team monitor Otevřít okno terminálu
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Pro restart podržte klávesy CONTROL+ALT+DELETE po dobu # sekundy.}other{Pro restart podržte klávesy CONTROL+ALT+DELETE po dobu # sekund.}}
Restart the desktop Team monitor Restartovat plochu
Force reboot Team monitor Vynutit restart
Team monitor Team monitor Monitor týmů
Kill application Team monitor Zabít aplikaci
Cancel Team monitor Zrušit
(This team is a system component) Team monitor (Tento tým je součástí systému)
1 greek, modern (1453-) x-vnd.Haiku-KeyboardInputServerDevice 1085266673
1 greek, modern (1453-) x-vnd.Haiku-KeyboardInputServerDevice 131044710
If the application will not quit you may have to kill it. Team monitor Αν η εφαρμογή δεν κλείσει, θα πρέπει ενδεχομένως να την τερματίσετε εξαναγκαστικά.
Quit application Team monitor Κλείσιμο εφαρμογής
Open Terminal Team monitor Άνοιγμα Τερματικού
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Πατήστε CONTROL+ALT+DELETE για # δευτερόλεπτο για επανεκκίνηση.}other{Πατήστε CONTROL+ALT+DELETE για # δευτερόλεπτα για επανεκκίνηση.}}
Restart the desktop Team monitor Επαννεκίνηση
Force reboot Team monitor Εξαναγκαστική επανεκκίνηση
1 indonesian x-vnd.Haiku-KeyboardInputServerDevice 2228550365
1 indonesian x-vnd.Haiku-KeyboardInputServerDevice 131044710
If the application will not quit you may have to kill it. Team monitor Jika aplikasi tidak mau keluar anda mungkin harus mematikannya.
Quit application Team monitor Keluar dari aplikasi
Restart the desktop Team monitor Start ulang desktop
Quit application Team monitor Keluar aplikasi
Open Terminal Team monitor Buka Terminal
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Tahan CONTROL+ALT+DELETE selama # detik untuk mulai ulang.}other{Tahan CONTROL+ALT+DELETE selama # detik untuk mulai ulang.}}
Restart the desktop Team monitor Mulai ulang desktop
Force reboot Team monitor Paksa restart
Team monitor Team monitor Monitor tim
Team monitor Team monitor Pemantau tim
Kill application Team monitor Matikan aplikasi
Cancel Team monitor Batal
(This team is a system component) Team monitor (Tim ini adalah komponen sistem)
1 japanese x-vnd.Haiku-KeyboardInputServerDevice 131044710
If the application will not quit you may have to kill it. Team monitor アプリケーションが終了しない場合は、強制終了しないといけないかもしれません。
Quit application Team monitor アプリケーションを終了
Quit application Team monitor アプリケーションの終了
Open Terminal Team monitor ターミナルを開く
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{CONTROL+ALT+DELETE を # 秒押すと再起動します。}other{Hold CONTROL+ALT+DELETE を # 秒押すと再起動します。}}
Restart the desktop Team monitor デスクトップを再起動
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{CONTROL+ALT+DELETE を # 秒押すと再起動します。}other{CONTROL+ALT+DELETE を # 秒押すと再起動します。}}
Restart the desktop Team monitor デスクトップの再起動
Force reboot Team monitor 強制再起動
Team monitor Team monitor チームモニター
Kill application Team monitor アプリケーションを強制終了
Kill application Team monitor アプリケーションの強制終了
Cancel Team monitor 中止
(This team is a system component) Team monitor (このチームはシステムの構成要素です)
If the application will not quit you may have to kill it. Team monitor Als de toepassing niet afsluit moet je het misschien afbreken.
Quit application Team monitor Toepassing afsluiten
Open Terminal Team monitor Open Terminal
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Houd CONTROL+ALT+DELETE # seconde ingedrukt om te herstarten.}other{Houd CONTROL+ALT+DELETE ingedrukt voor # seconden om te herstarten.}}
Restart the desktop Team monitor Start het bureaublad opnieuw
If the application will not quit you may have to kill it. Team monitor Jeżeli aplikacja nie zakończy działania, być może trzeba będzie ją zabić.
Quit application Team monitor Zakończ aplikację
Open Terminal Team monitor Uruchom Terminal
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Przytrzymaj CONTROL+ALT+DELETE przez # sekundę, aby uruchomić system ponownie.} few{Przytrzymaj CONTROL+ALT+DELETE przez # sekundy, aby uruchomić system ponownie.} many{Przytrzymaj CONTROL+ALT+DELETE przez # sekund, aby uruchomić system ponownie.} other{Przytrzymaj CONTROL+ALT+DELETE przez # sekundy, aby uruchomić system ponownie.}}
Restart the desktop Team monitor Uruchom pulpit ponownie
Force reboot Team monitor Wymuś ponowne uruchomienie komputera
If the application will not quit you may have to kill it. Team monitor Se o aplicativo não for encerrado, talvez seja necessário matá-lo.
Quit application Team monitor Sair do aplicativo
Open Terminal Team monitor Abrir Terminal
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Segure CONTROL+ALT+DELETE por # segundo para reiniciar.}other{Segure CONTROL+ALT+DELETE por # segundos para reiniciar.}}
Restart the desktop Team monitor Reiniciar a área de trabalho
Force reboot Team monitor Forçar a reinicialização
1 romanian x-vnd.Haiku-KeyboardInputServerDevice 131044710
If the application will not quit you may have to kill it. Team monitor Dacă aplicația nu se închide va trebui să o termini forțat.
Quit application Team monitor Închide aplicația
If the application will not quit you may have to kill it. Team monitor Dacă aplicația nu se închide, va trebui să o terminați.
Quit application Team monitor Părăsește aplicația
Open Terminal Team monitor Deschide Terminal
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}}
Restart the desktop Team monitor Repornește desktopul
Force reboot Team monitor Forțează repornirea
Team monitor Team monitor Monitor echipe
Team monitor Team monitor Monitor de echipă
Kill application Team monitor Termină aplicația
Cancel Team monitor Anulează
(This team is a system component) Team monitor (Această echipă este o componentă de sistem)
If the application will not quit you may have to kill it. Team monitor Если приложение не завершится, возможно вам понадобиться убить его.
Quit application Team monitor Завершить приложение
Open Terminal Team monitor Запустить Терминал
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{Удерживайте CONTROL+ALT+DELETE в течение # секунды для перезагрузки.}other{Удерживайте CONTROL+ALT+DELETE в течение # секунд для перезагрузки.}}
Restart the desktop Team monitor Перезапустить рабочий стол
Force reboot Team monitor Перезагрузить принудительно
1 english x-vnd.Haiku-KeyboardInputServerDevice 2228550365
1 english x-vnd.Haiku-KeyboardInputServerDevice 131044710
If the application will not quit you may have to kill it. Team monitor 如果该程序无法退出，您可能需要将其杀死。
Quit application Team monitor 退出程序
Open Terminal Team monitor 打开终端
{0, plural,one{Hold CONTROL+ALT+DELETE for # second to reboot.}other{Hold CONTROL+ALT+DELETE for # seconds to reboot.}} Team monitor {0, plural,one{按下 CONTROL+ALT+DELETE 等待 # 秒后重新启动。}other{按下 CONTROL+ALT+DELETE 等待 # 秒后重新启动。}}
Match \"%attribute\" against \"%regex\" RuleFilter Shoda \"%attribute\" vůči \"%regex\"
Match header RuleFilter Shoda hlavičky
Set flags to ConfigView Nastavit příznaky na
Header field (e.g. Subject, From, …) ConfigView Hlavička (např. Předmět, Od, ...)
<Choose account> ConfigView <Zvolte účet>
Wildcard value like \"*spam*\".\nPrefix with \"REGEX:\" in order to use regular expressions. ConfigView Hodnota se zástupnými znaky jako například \"*spam*\".\nPoužijte předponu \"REGEX:\" pokud chcete použít regulární výraz.
Then ConfigView Pak
If ConfigView Jestliže
Set as read ConfigView Nastavit jako přečtené
Reply with ConfigView Odpovědět pomocí
<Choose action> ConfigView <Zvolte akci>
Move to ConfigView Přesunout do
this field is based on the action ConfigView toto pole je založeno na operaci
Match \"%attribute\" against \"%regex\" RuleFilter Cocokkan \"%attribute\" terhadap \"%regex\"
Match header RuleFilter Cocokan tajuk
Set flags to ConfigView Setel bendera ke
Set flags to ConfigView Atur bendera ke
Header field (e.g. Subject, From, …) ConfigView Bidang tajuk (misal. Subyek, Dari, …)
<Choose account> ConfigView <Pilih akun>
Wildcard value like \"*spam*\".\nPrefix with \"REGEX:\" in order to use regular expressions. ConfigView Nilai wildcard seperti \"*spam*\".\nDiawali dengan \"REGEX:\" untuk menggunakan expresi-ekspresi reguler.
Wildcard value like \"*spam*\".\nPrefix with \"REGEX:\" in order to use regular expressions. ConfigView ワイルドカード値は \"*spam*\" のようなものです。\n正規表現を使用するには、先頭に \"REGEX:\" をつけてください。
Then ConfigView ならば
If ConfigView 条件:
If ConfigView 条件
Set as read ConfigView 既読にする
Reply with ConfigView 返事を書く
<Choose action> ConfigView <動作を選択>
<Choose action> ConfigView <動作の選択>
Move to ConfigView に移動する
this field is based on the action ConfigView ここは動作によって意味が変わります
Set flags to ConfigView Definir sinalizadores para
Header field (e.g. Subject, From, …) ConfigView Campo de cabeçalho (ex.: Assunto, De, …)
<Choose account> ConfigView <Escolher conta>
Wildcard value like \"*spam*\".\nPrefix with \"REGEX:\" in order to use regular expressions. ConfigView Valor curinga, como \"*spam*\".\nPara usar expressões regulares, utilize o prefixo \"REGEX:\"
Wildcard value like \"*spam*\".\nPrefix with \"REGEX:\" in order to use regular expressions. ConfigView Valor curinga como \"*spam*\".\nPrefixo com \"REGEX:\" para usar expressões regulares.
Match \"%attribute\" against \"%regex\" RuleFilter Potrivește \„%attribute\” peste \„%regex\”
Match header RuleFilter Potrivește antet
Set flags to ConfigView Stabilește indicatorii la
Match header RuleFilter Potrivește antetul
Set flags to ConfigView Stabilește fanioanele la
Header field (e.g. Subject, From, …) ConfigView Fișier antet (de ex. Subiect, De la, …)
<Choose account> ConfigView <Selectează contul>
<Choose account> ConfigView <Choose account>
Wildcard value like \"*spam*\".\nPrefix with \"REGEX:\" in order to use regular expressions. ConfigView O valoare de metacaracter precum \„*spam*\”.\nPrefixați cu \„REGEX:\” pentru a utiliza expresii regulate.
Then ConfigView Atunci
If ConfigView Dacă
Set as read ConfigView Marchează ca citit
Set as read ConfigView Stabilește la citit
Reply with ConfigView Răspunde cu
<Choose action> ConfigView <Selectează acțiunea>
<Choose action> ConfigView <Choose action>
Move to ConfigView Mută la
this field is based on the action ConfigView acest câmp este bazat pe acțiunea
New mails notification NotifierFilter Паведамленне пра новую пошту
Alert NotifierConfigView Паведамленне
OK NotifierFilter Добра
Central alert NotifierConfigView Цэнтральнае паведамленне
Beep NotifierConfigView Гукавы сігнал
Central beep NotifierConfigView Цэнтральны гукавы сігнал
{0, plural, one{One new message} other{# new messages}} NotifierFilter {0, plural, one{Адно новае паведамленне} few{# новых паведамленняў} other{# новых паведамленняў}}
New mails notification NotifierFilter Upozornění na nové zprávy
Alert NotifierConfigView Upozornění
OK NotifierFilter OK
Central alert NotifierConfigView Centrální upozornění
Beep NotifierConfigView Pípnutí
Central beep NotifierConfigView Centrální pípnutí
{0, plural, one{One new message} other{# new messages}} NotifierFilter {0, plural, one{Jedna nová zpráva} few{# nové zprávy} other{# nových zpráv}}
New messages NotifierFilter Nové zprávy
Method: NotifierConfigView Metoda:
Keyboard LEDs NotifierConfigView LED klávesnice
You have {0, plural, one{one new message} other{# new messages}} for %account. NotifierFilter Máte {0, plural, one{jednu novou zprávu} few{# nové zprávy} other{# nových zpráv}} na %account.
New mails notification NotifierFilter Notificação de novas mensagens
New mails notification NotifierFilter Notificação de novos e-mails
Alert NotifierConfigView Alerta
OK NotifierFilter OK
Central alert NotifierConfigView Alerta central
Beep NotifierConfigView Alarme sonoro
Central beep NotifierConfigView Alarme sonoro central
{0, plural, one{One new message} other{# new messages}} NotifierFilter {0, plural, one{Uma nova mensagem} other{# novas mensagens}}
New messages NotifierFilter Novas mensagens
Method: NotifierConfigView Método:
Keyboard LEDs NotifierConfigView LEDs do teclado
You have {0, plural, one{one new message} other{# new messages}} for %account. NotifierFilter Você tem {0, plural, one{uma nova mensagem} other{# novas mensagems}} para %account.
1 romanian x-vnd.Haiku-NewMailNotification 1375000288
Log window NotifierConfigView Fereastră istoric
none NotifierConfigView nimic
New mails notification NotifierFilter Înștiințare mailuri noi
Log window NotifierConfigView Fereastră de jurnal
none NotifierConfigView nespecificat
New mails notification NotifierFilter Notificare emailuri noi
Alert NotifierConfigView Alertă
OK NotifierFilter OK
Central alert NotifierConfigView Alertă centrală
Beep NotifierConfigView Bip
Central beep NotifierConfigView Bip central
{0, plural, one{One new message} other{# new messages}} NotifierFilter {0, plural, one{Un mesaj nou} other{# mesaje noi}}
{0, plural, one{One new message} other{# new messages}} NotifierFilter {0, plural, one{One new message} other{# new messages}}
New messages NotifierFilter Mesaje noi
Method: NotifierConfigView Metodă:
Keyboard LEDs NotifierConfigView LEDuri tastatură
Keyboard LEDs NotifierConfigView LEDuri de tastatură
You have {0, plural, one{one new message} other{# new messages}} for %account. NotifierFilter Aveți {0, plural, one{one new message} other{# new messages}} pentru %account.
1 english x-vnd.Haiku-NewMailNotification 2111731137
1 english x-vnd.Haiku-NewMailNotification 1375000288
Log window NotifierConfigView 日志窗口
none NotifierConfigView 无
New mails notification NotifierFilter 新邮件通知
@ -11,3 +11,4 @@ Central beep NotifierConfigView 中部蜂鸣
New messages NotifierFilter 新消息
Method: NotifierConfigView 方法：
Keyboard LEDs NotifierConfigView 键盘LED
You have {0, plural, one{one new message} other{# new messages}} for %account. NotifierFilter 您的账户 %account 有 {0, plural, one{one new message} other{# new messages}}
David Karoly
Pascal Abresch
