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.
All other browsers have it default-off (if there is even a way to
enable it.) This makes it much easier to use Web+ on HiDPI, though
ideally it would automatically set a zoom factor on startup
correspondent to the system font size.
This takes care of making sure the dirent buffer is properly aligned,
which it needs to be on some platforms (SPARC, ARM, etc.)
Change-Id: I9a6352b1e654c090a200770d51f96511ee024a99
Originally _r mostly avoided the buffers in the DIR* and invoked
_kern_read_dir correctly, however that did not interact properly
with the non-reentrant functions and so this method was reworked
some years ago to check entries_left and copy results out of the buffer.
However, that was done improperly; it just copied the structs,
which as they have a VLA at the end, meant the name entry was not
copied at all if an entry was read out of the buffer.
Since we have to read entries out of the buffer anyway,
just invoke the real readdir() and then memcpy what it returns.
Use an ErrnoMaintainer to prevent errno from being affected.
...as was already added to the regular (userland) StaticLibrary some
time ago. Shaves off double-digit percentages of the file size of
e.g. FreeBSD and OpenBSD network drivers.
Instead of checking against the current block's DSO generation,
the DSO that the operator[] was invoked on was being checked instead.
This could lead to spurious deletions of TLS data in the case where
the generation count changed between accesses of the TLS variable
(currently that only happens when modules are unloaded.)
May fix#17896, but I did not have a reliable way to reproduce that.
Change-Id: Ie1ee51c1fbbe638918fd5a010047a2b56d481f2b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5604
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Mostly for HiDPI, but this also cleans up the code in general, too.
* Apply a scale-factor when loading and serializing column size/offsets
in ViewState.
* Do not hard-code offset values for default columns but let
BPoseView::AddColumn() compute them manually instead.
* Change BPoseView::AddColumn() to support being called during
early initialization and utilize it in SetUpDefaultColumns...().
* When adding deserialized columns to a BPoseView, always realign
the offsets instead of just doing sanity checking. The rationale here
is that the first time the TitleView is touched, it will do this
anyway, and cause "snapping" or drawing glitches if the alignment
is not as expected.
If it was actually somehow an intended feature that non-adjacent
columns can be displayed, changes are needed in TitleView and PoseView
to properly support this without triggering redraw glitches.
I still saw some very slight redraw glitches (e.g. column contents
shifting by 1px) at higher font sizes; however, Tracker before this
commit had far more of those glitches (this commit seems to resolve
a number of them.)
Tested with 12pt, 18pt, and 20pt font sizes; this seems to work
pretty well. But if you see strange behavior or more redraw glitches
than there were previously, please do file a ticket.
Augustin Cavalier