This enforces us to remove duplicated code across the SysFS code. This
results in great simplification of how the SysFS works now, because we
enforce one way to treat SysFSDirectory objects.
This will be used later on to help connecting a node at /sys/dev/block/
that represents a Storage device to a directory in /sys/devices/storage/
with details on that device in that directory.
These methods will be used later on to introduce symbolic links support
in the SysFS, so the kernel will be able to resolve relative paths of
components in filesystem based on using the m_parent_directory pointer
in each SysFSComponent object.
LUN address is essentially how people used to address SCSI devices back
in the day we had these devices more in use. However, SCSI was taken as
an abstraction layer for many Unix and Unix-like systems, so it still
common to see LUN addresses in use. In Serenity, we don't really provide
such abstraction layer, and therefore until now, we didn't use LUNs too.
However (again), this changes, as we want to let users to address their
devices under SysFS easily. LUNs make sense in that regard, because they
can be easily adapted to different interfaces besides SCSI.
For example, for legacy ATA hard drive being connected to the first IDE
controller which was enumerated on the PCI bus, and then to the primary
channel as slave device, the LUN address would be 0:0:1.
To make this happen, we add unique ID number to each StorageController,
which increments by 1 for each new instance of StorageController. Then,
we adapt the ATA and NVMe devices to use these numbers and generate LUN
in the construction time.
This folder in the SysFS code represents everything related to /sys/dev,
which is a directory meant to be a convenient interface to track all IDs
of all block and character devices (ID = major:minor numbers).
This bug was probably around for a very long time, but it is noticeable
only under VirtualBox as it generated an non fatal error which caused a
kernel panic because we VERIFYed the wrong lock to be locked.
There's no point in keeping this method as we don't really care if a
graphics adapter is VGA compatible or not because we don't use this
method anymore.
There's no real value in separating physical pages to supervisor and
user types, so let's remove the concept and just let everyone to use
"user" physical pages which can be allocated from any PhysicalRegion
we want to use. Later on, we will remove the "user" prefix as this
prefix is not needed anymore.
This new command allows you to run any command with an initial set
of pledge promises.
Note that dynamically linked executables won't be able to bootstrap
without at least "stdio rpath prot_exec".
Inspired by http://justine.lol/pledge/ :^)
We now remove default route and set IP address to 0.0.0.0 (Kernel
interprets this as "link down") for all disabled interfaces, so that
a reboot is no longer needed.
This patch makes the function signature of the on_bookmark_click handler
more readable by replacing `Mod_None` with `OpenInNewTab::No` and
`Mod_Ctrl` with `OpenInNewTab::Yes`.
We are limited on the amount of supervisor pages we can allocate, so
don't allocate from that pool. Supervisor pages are always below 16 MiB
barrier so using those was crucial when we used devices like the ISA
SoundBlaster 16 card, because that device required very low physical
addresses to be used.
When using the kernel console, there's no such concept of title at all.
Also, this makes vim to crash the kernel due to dereferencing a null
pointer, so let's remove this as this is clearly not needed when using
the kernel virtual console.
This used to be needed to protect accesses to Process::all_instances.
That list now has a more granular lock, so we don't need to take the
scheduler lock.
This fixes a crash when we try to access a locked Thread::m_fds in the
loop, which calls Thread::block, which then asserts that the scheduler
lock must not be locked by the current process.
Fixes#13617
Usually operations that mirror AOs from the Infra spec are simply part
of the underlying data structures in AK directly, but these don't seem
generally useful enough to add them as ByteBuffer methods.
