The previous logic of _AddTrim plus _TrimNext meant that if a trim
range was specified in the final call to _TrimNext (i.e. with force=true),
but the trim buffer was already full at that point, that last range
would not actually be trimmed.
Now, _AddTrim returns true when the buffer is filled and trimming
should be done, rather than delaying it and requiring a second
add after trimming.
Change-Id: I4b782948e8dc9267c63e61bce0c078fd4e834177
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6070
Tested-by: Automation <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
..instead of readv_pos/writev_pos. This way, we can be sure that we
are remapping them properly even under Haiku, as well as remove some
potential confusions.
bfs_shell seems to still work fine on a regular build.
All drivers using IORequest should have any problems here already caught
by it, and overruns in other drivers would overrun the buffer and cause
corruptions, so we should no longer silently be ignoring this,
presuming it is still a problem at all.
As the TODO comment indicated that this logic could also be used for
writes if this wasn't a problem, I have added a separate TODO for that.
They are not about reading and writing pages, but just iovecs.
As the passed iovecs use void*s, it can't possibly be working with
physical pages on 32-bit systems with PAE.
It appears nothing uses or implements these functions anyway,
as there was nothing else in the tree I had to adjust after making
this change...
It was used only for playing CDs via SCSI commands, which is what
CDPlayer also did; but this is not really much supported anymore,
so CDPlayer was removed years ago, and now this is too.
Its source code lives on at HaikuArchives.
Fixes#18236.
errno is a thread-local variable, we can't read it in another thread
and have the value make any sense. Thus we need to store it.
Fortunately, as our errors are all negative already, we can just put it
directly in fFD instead of having to make a new variable altogether.
Should help with diagnosing a problem seen in some syslogs.
Just a straight code import, various things need to be done before
it will compile and actually work.
Change-Id: Ibb3629a14067d350d58e2066bafc64a901d6a85e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6040
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This is duplicated across multiple filesystems, and could probably be
used in more still.
Adjusted only BFS, EXT2, and NTFS in this commit, as they are the ones
which make use of fs_ops_support.h already and thus need to be modified
to avoid duplicate-definition errors.
Also tweak next_dirent to support being built under fs_shell.
(Possibly we should define ASSERT there, though?)
This required the addition of some slight modifications to the main
(FreeBSD compat) bus_dma implementation.
Allows some #ifdefs from iaxwifi/idualwifi to be dropped, and will
ease the porting of some future drivers.
Tested with idualwifi7260, seems to work as before.
Note that zstd-compressed packages cannot be installed unless the
running system can already read them, even as part of a system
update transaction. This has been possible for some months now,
but if one has an older EFI bootloader, you may need to upgrade it.
Change-Id: I9e561459477723e498a871ee5c5caad560861b79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4663
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
We need O_CLOEXEC here, not FD_CLOEXEC (which is equal to 0x1, which
in openflags is O_WRONLY and thus leads to the conflicts caught by
the previous commit.)
Fixeshaikuports/haikuports#7524.
(cherry picked from commit 59e09f7bebcb8fa9d4ed82f501e6516c3d67d65b)
Change-Id: I5751822ac48ae7a865755494da241e4bfd34c45f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5853
Reviewed-by: waddlesplash <[email protected]>
Otherwise we will have open modes that could have both and lead to
confusion in code that presumes only one will be set.
This catches the cause of some ported software (e.g. Wayland layer)
misbehaving with ramfs mounted in /var/shared_memory: the ramfs does not
properly handle both flags set, and due to another bug, they are for
shm_open'ed files.
(cherry picked from commit 9bc250e28d3bb4293c39a283807b67b6e82dda1d)
Change-Id: I9e98be89b6d4a2da90f74c048b4f762ca9cf8738
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5852
Reviewed-by: waddlesplash <[email protected]>
This saves 16 bytes in the class vs. the old size, but more importantly
allows us to avoid allocating VMCaches and wasting an entire page for
any attribute larger than 32 bytes; instead, attributes can be up to
1024 bytes before we allocate a full page for them.
Unfortunately small files cannot take advantage of this optimization
right now as the cache is always used for them. I added a TODO about
this.
* RemoveReference() could delete us immediately, thus we must do
all important work before invoking it.
* Add assertions about fRefCount and remove a spurious add.
* Do not use Link but PublishVNode on the root, as we manually manage
when this object is published/deleted.
Fixes#18032.
* We do not want to set fNode in the constructor but let the invocation
of Link() take care of doing so instead.
* Link/Unlink manipulate linked-lists. Thus it is dangerous to use them
in tandem on the same Node object. Add a check for this.
* Minor cleanup.
No functional change as-is, but this is necessary with some experimental
patches I am testing which add a lot more assertions to DoublyLinkedList,
which thus require it to have constructors/destructors for the Link class.
Previously it was spread all around the tree, and was not defined
consistently for all boot objects (there were a number of boot modules
which did not define it, but did include headers which checked for it.)
Now, as it is handled in SetupBoot which is invoked for all boot objects,
it will be applied consistently throughout. We can thus drop the manual
additions of it from all Jamfiles.
The rest of the code does a memcpy(..., ..., min(11, strlen(...))
so clearly no NULL terminator is needed and 11 is the real limit.
Should fix#18074.
Change-Id: I6aea166899eab2bab9511ca52981ccc9172b6c17
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5823
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
This was initially added so users on the nightlies would not wind up
with no translators installed on updates. It has been long enough
that we can probably remove this in master. (I will re-add it
in the beta4 branch for users upgrading directly from beta3 -> beta4.)
This breaks ABI as we forgot to do this originally and a lot of apps
implicitly use symbols from libbe or elsewhere that are imported from
libshared, but we are about to branch beta4, so now is the time to
change this.
Fixes#17256.
* Nothing in the tree and few things outside it used BIG_{SPACING|INSETS};
it seems a value of 15px (at default font size) is not that useful.
There are, however, a lot of things around the tree that use multiples
of 20px. So, make BIG be that, with the intent to replace those
with BIG directly.
* Introduce CORNER_{SPACING|INSETS}. There are a lot of applications
(e.g. Tracker, Terminal, Debugger etc.) which use scroll bar width/height
to metrically align controls with the window frame or with some other
control which contains scroll bars. Rather than have to invoke
BScrollBar or BControlLook directly to get the value, we should just
derive the size of scrollbars from a spacing constant instead
and get rid of the custom function. (For now it is just replaced.)
This reuses the old values for BIG, as it is equal to 14px at default.
* Introduce BORDER_{SPACING|INSETS}. This is equal to the typical border
size of 1px at default font size (or lower) and uses floor() instead of
ciel() to compute what the size should be (i.e. it will remain 1px
at 150%/18pt and only go up at 200%/24pt.) This will allow a lot of
the hardcoded border sizes around the tree and elsewhere to use
ComposeSpacing() instead.
Change-Id: Iaea3fa30364859888e816a9d61ac156268d70758
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5702
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: nephele <[email protected]>
Tested-by: Commit checker robot <[email protected]>
vnode deletion is prevent either by owning a reference to the node,
or by being at least a reader of the vnodes lock. Thus, in acquire_vnode,
we have to inc_ref_count while still holding the lock in order to prevent
a race.
This function is used so rarely and quite deep inside FS drivers that
I'm not sure this race would ever have been a problem. Nonetheless
the old code was incorrect.
Most of the time, that is harmless and will just cause a slight delay
before the vnode is removed and we return NULL instead of finding it.
However, in rare circumstances involving renames, we can wind up in
a deadlock with the thread that is trying to remove the vnode, and
would have to wait all the way to the timeout (a full ten seconds!).
The only vnodes not about to disappear from the table that can be both
"removed" and "busy" seem to be special vnodes like pipes, which will
be in an "unpublished" state while they are initially "busy" which we
can check for, in case something wants to wait for them.
The "dirconc" test readily triggered a pathological case of this behavior.
Before this commit, it ran for over 15 minutes before I killed it (and
it was not close to done at that point, either.) After this change,
it completes successfully in around 3 minutes or so on my test VM.
Thanks to [email protected] for pointing out this testcase and its
misbehavior on Haiku!
Change-Id: Id1accf0aaf0724e1aec927a437d3a2ac1596cd98
The GetNextNetwork() method is really inefficient: it fetches all the
networks at once from the kernel every single time and then winds
up returning only one of them. In parts of the GUI that iterate over
all networks more than once per refresh (sometimes within a loop, even!)
this was often a noticeable lag on the GUI, especially with OpenBSD
drivers which have extra overhead to do struct translation in the
ioctl handler.
Now, we have a way to fetch all scan results at once and just iterate
over them as many times as we need, and this is what NetworkStatus
and Network preferences now do, saving lots of time and effort.
These were not maintained here, merely mirrored from the Userguide Translator,
and rather infrequently at that. But as they were built with Haiku,
that meant new versions of these packages were built every hrev,
which meant a lot of wasted space and bandwith for updates.
Now there is a separate "userguide" repository which will collect the
files exported from the Translator, and recipes at HaikuPorts to build
the packages, instead, so we can delete these files from this repo.
They are now created from a separate repository and via HaikuPorts.
Since the HaikuPorts packages are not yet in the BuildPackageRepository,
the actual section that adds the packages is commented out (but it only
runs for release-* targets anyway.)
The "welcome", "userguide", and "quicktour" scripts, which are symlinked
from the desktop in release builds, are added to the Haiku package's
"regular" profile instead (they do not actually require the other packages
to be installed but will detect if they are not and launch the online
versions instead.)
Before implementing interrupts, all I/O was polled.
Now we only use polling as fallback if interrupts mode
does not work for some reason.
Should fix#17484.
* Set only a minimum width and then resize to preferred on window.
* Set a minimum height for the text view itself.
* Use the new TextView controls instead of the old BTextView.
* Adjust other size constraints as needed.
Fixes#17998.
Ideally DesktopSettings would take care of this. However, we cannot
put this logic into its _SetDefaults, because that runs before
we actually set (or confirm) a display mode, and so attempts to fetch
the display mode in that function will fail.
(FontManager initializes even earlier and thus also is an unsuitable
place for this logic.)
At present, it merely uses a 2x larger font size at resolutions >"4K"
and a 1.5x larger font size at resolutions between 1080p and 4K.
Further adjustments can be made as necessary later on.
This code has been this way since the initial import to OpenTracker,
so why or how it wound up in here is a mystery which may remain unsolved.
Removing it does not seem to cause any problems, so let's do that.
Fixes#16625.
FreeBSD puts these in ifq.h (which we do not have), and no driver we
have actually uses them.
We can re-add the newer versions of them if we ever import a driver
which does.
The old alias had a number of shortcomings which made it not match
OpenBSD and thus special-casing had to be used in drivers. The new
version should match OpenBSD's semantics precisely.
Augustin Cavalier