This should fix the flaky tests of test-js.
It also fixes the tests when running with the -g flag since the values
will not be garbage collected too soon.
It isn't needed.
Also, we stopped linking Kernel against it in 67f0c0d5f0. libsupc++
depends on symbols like free() or realloc() which we removed from
Kernel/StdLib.cpp after 67f0c0d5f0 and which don't exist in Prekernel
either.
(It also happens to make the aarc64 link fail in less obvious ways.)
This is really a basic support for AHCI hotplug events, so we know how
to add a node representing the device in /sys/dev/block and removing it
according to the event type (insertion/removal).
This change doesn't take into account what happens if the device was
mounted or a read/write operation is being handled.
For this to work correctly, StorageManagement now uses the Singleton
container, as it might be accessed simultaneously from many CPUs
for hotplug events. DiskPartition holds a WeakPtr instead of a RefPtr,
to allow removal of a StorageDevice object from the heap.
StorageDevices are now stored and being referenced to via an
IntrusiveList to make it easier to remove them on hotplug event.
In future changes, all of the stated above might change, but for now,
this commit represents the least amount of changes to make everything
to work correctly.
We are no longer have a separate Inode object class for the pts
directory. With a small exception to this, all chmod and chown code
is now at one place.
It's now possible to create any name of a sub-directory in the
filesystem.
The current implementation of DevFS resembles the linux devtmpfs, and
not the traditional DevFS, so let's rename it to better represent the
direction of the development in regard to this filesystem.
The abbreviation for DevTmpFS is still "dev", because it doesn't add
value as a commandline option to make it longer.
In quick summary - DevFS in unix OSes is simply a static filesystem, so
device nodes are generated and removed by the kernel code. DevTmpFS
is a "modern reinvention" of the DevFS, so it is much more like a TmpFS
in the sense that not only it's stored entirely in RAM, but the userland
is responsible to add and remove devices nodes as it sees fit, and no
kernel code is directly being involved to keep the filesystem in sync.
In order to make this kind of operation simpler, we no longer use a
Vector to store pointers to DevFSDeviceInode, but an IntrusiveList is
used instead. Also, we only allow to remove device nodes for now, but
in theory we can allow to remove all kinds of files from the DevFS.
While traversing in both /sys/dev/char and /sys/dev/block, SystemServer
populates the DevFS (mounted normally in /dev) with the corresponding
device nodes.
This is a very crude implementation of populating DevFS device nodes,
before we have a full-fledged udev-like daemon to take care of this
task. Also, we don't populate DiskPartition device nodes yet, because
that requires more sophisticated mechanism to figure out which
DiskPartition is related to which StorageDevice.
These files are not marked as block devices or character devices so they
are not meant to be used as device nodes. The filenames are formatted to
the pattern "major:minor", but a Userland program need to call the parse
these format and inspect the the major and minor numbers and create the
real device nodes in /dev.
Later on, it might be a good idea to ensure we don't create new
SysFSComponents on the heap for each Device, but rather generate
them only when required (and preferably to not create a SysFSComponent
at all if possible).
Devices might be removed and inserted at anytime, so let's ensure we
always do these kind of operations with a good known state of the
HashMap.
The VirtIO code was modified to create devices outside the IRQ handler,
so now it works with the new locking of the devices singleton, but a
better approach might be needed later on.
These methods are no longer needed because SystemServer is able to
populate the DevFS on its own.
Device absolute_path no longer assume a path to the /dev location,
because it really should not assume any path to a Device node.
Because StorageManagement still needs to know the storage name, we
declare a virtual method only for StorageDevices to override, but this
technique should really be removed later on.
Don't create these device nodes in the Kernel, so we essentially enforce
userspace (SystemServer) to take control of this operation and to decide
how to create these device nodes.
This makes the DevFS to resemble linux devtmpfs, and allows us to remove
a bunch of unneeded overriding implementations of device name creation
in the Kernel.
This bit me because I accidentally made the destructor for a class which
was wrapped in an Optional private. This causes none of the Optional
destructors to be able to be deduced, which when combined with concepts
causes an internal compile error in GCC 10.3.0+. This commit adds a note
here to make sure that future encounters of this bug does not surprise
people.
TmpFS inodes rely on the call to Inode::one_ref_left() to unregister
themselves from the inode cache in TmpFS.
When moving various kernel classes to ListedRefCounted for safe unref()
while participating on lists, I forgot to make ListedRefCounted check
for (and call) one_ref_left() & will_be_destroyed() on the CRTP class.
Ninja disables its fancy output mode when it's not writing to a TTY.
So don't pipe its output into something else, so that it writes to
a TTY if the invoking terminal is a TTY.
`LLVM_LLVM_BUILD_LLVM_DYLIB` does not exist, so passing this does
nothing but make CMake warn.
However, since we pass `LLVM_LINK_LLVM_DYLIB`, `LLVM_BUILD_LLVM_DYLIB`
(the correct spelling) defaults to true anyways. So let's pass fewer
flags.
No behavior change, but fixes a CMake warning.
I was building serenity on quite a fresh NixOS system and it turns
out `unzip` and `qemu` were missing from this nix expression to
compile and run serenity.
No major engine allows whitespace in the type when checking for
"module".
This was also reflected in the relevant web platform test, but not in
the spec.
The spec has been changed to match this behaviour: 23c723e3e9
Showing the position only with an active tool seems a bit confusing,
if you've opened up an image just to find out the coordinates of
a pixel for instance, there shouldn't be a need to have to select
a tool first.
Previously, we were ignoring the scale of the editor in the second
paint step. If you were zoomed in, the size while you were drawing
was not the same as the size of the final shape.
Previously, we were ignoring the scale of the editor in the second
paint step. If you were zoomed in, the size while you were drawing
was not the same as the size of the final shape.
Previously, we were ignoring the scale of the editor in the second
paint step. If you were zoomed in, the size while you were drawing
was not the same as the size of the final shape.
