Building with more than one job appears to broken.
Additionally, it relies on incomplete function prototypes, which C23
removed support for.
Furthermore, it doesn't build without
`-Wno-error=incompatible-pointer-types` anymore, as it passes
incorrect function pointer types to `qsort()`.
macOS ships tic 6.0.20150808 which fails to build terminfo for
ncurses 6.5. Bump the minimum required version to 6.1 so the
Homebrew tic is used instead.
This is once again very limited. We only support one `curve25519-sha256`
for the key exchange and `ssh-ed25519` as the host key.
With the SSH_DEBUG macro set and connecting from my host, it now prints:
```
Client protocol string: SSH-2.0-OpenSSH_10.0p2 Ubuntu-5ubuntu5
KEXINIT message sent
KEX_ECDH_REPLY message sent
error: Draw the rest of the owl
```
The client seems happy with the key exchange, and the following message
is encrypted!
That functionality seems to be too much complicated.
We shouldn't overengineer how the copy_mount syscall works, so instead
of allowing replacement of the root filesystem, let's make the unshare
file descriptor to be configured via a special ioctl call before we
initialize a new VFSRootContext object.
The special ioctl can either set a new root filesystem for the upcoming
VFSRootContext object, or remove it (by passing fd of -1).
If there's no specified root filesystem, a new RAMFS instance will be
created automatically when invoking the unshare_create syscall.
This also simplifies the code in the boot process, hence making it much
more readable.
It should be noted, that we assumed during pivot_root that the first
mountpoint in a context is the root mountpoint, which is probably a fair
assumption, but we don't assume this anywhere else in the VFSRootContext
code.
If this functionality ever comes back, we should ensure that we make
some effort to not assume this again.
Instead of creating a new resource that has its own ID number and work
with it directly, we can create a file that describes the unshared
resource, execute ioctl calls on it and only enter into it in the end,
essentially creating the resource only during the last call instead
of the previous method of creation of a resource when "attaching" to
that resource.
We can enter a resource for current program execution, after the exec
syscall, or both.
That change allows userspace to create a resource and attach to it only
in the new program, which makes it more comfortable to do cleanups or
track the new process, outside of the created container.
It should be noted that until this commit, we entered a resource without
detaching the old one, essentially leaking the attach counter of a
resource. While this bug didn't have severe effects, it was obvious that
a proper cleanup userspace code later on wouldn't work in that situation
anyway, so this commit changes the way we work, and the terminology of
entering a resource is actually to **replace** it.
These changes essentially open an opportunity to extend runc to be a
container manager rather being launcher of a containerized environment,
which makes it possible to do all sorts of nice cleanups and tracking of
containers' states.
We used major number 4 which is the major number for serial devices, not
a virtual console (e.g. /dev/ttyX).
This regressed probably a long time ago when there was a re-organization
of major numbers, and went unnoticed due to not being tested in such
scenario.
Therefore, I just put this patch as a quick fix, without trying to find
the exact commit which created this bug.
For the moment, the server starts listening on port 22 and then do the
protocol string exchange on connection. It aborts on any subsequent byte
received.
With the SSH_DEBUG macro set and connecting from my host, it prints:
```
Client protocol string: SSH-2.0-OpenSSH_10.0p2 Ubuntu-5ubuntu5
error: Draw the rest of the owl
```
I decided to add a LibSSH library, this will allow us to share some
code with an ssh client but for now, the main point is to easily be
able to add tests.
While `pc` is not particularly wrong on x86_64, it's nonsensical on
other supported platforms, namely aarch64 and riscv64.
For consistency, we now don't use this vendor anymore, regardless of the
platform.
Within the LLVM project, we now build as `$arch-serenity`. This is
enough in most cases, the only place where we have to specify a vendor
is the target .cfg file where we use `$arch-unknown-serenity`.
When building GCC and friends, again we simply identify as
`$arch-serenity` and this is enough.
As a result, the tools in Toolchain/Local/$arch/bin are now named after
this pattern: `$arch-serenity-$tool`.
These changes affect the toolchain build scripts, serenity's build
scripts and the Ports.
The last place where we should see `x86_64-pc-serenity` is the output of
`config.sub`, which assume the vendor is `pc` on vendor-less `x86*`
triples. So `x86_64-serenity` is expanded to `x86_64-pc-serenity`,
luckily enough and AFAICT, the whole GNU ecosystem considers `pc`,
`unknown` and vendor-less target triples the same. So `configure`
shouldn't have an issue finding the right tools anyway.
The gn files were edited with sed and are not tested.
This commit also includes a check in `Meta/serenity.sh` to give a nicer
error message when trying to build the system with an old toolchain.
----
To test this patch, on a clean tree I:
- Ran `./Meta/serenity.sh x86_64 GNU`
- Ran `./Toolchain/BuildJakt.sh`
- Tested these ports: python3(configure based), libjxl(cmake based) and
rizin(meson based)
- Also booted on aarch64 and risv64
I also repeated the steps above with a Clang toolchain.
On a working tree I tested all the affected ports, the results are:
- tinycc build fine but can't compile programs, I observed the same on
master.
- gdb and epsilon don't build but report the same errors as on master.
- I manually edited the libgpg-error, and it builds fine.
- The gcc port works fine.
For some reason, this will become necessary in the next commit. This
library is already included in glibc so it is not needed to link against
it on Linux, but otherwise required.
This allows us to stop using MemoryType::IO for the DMA buffer.
MemoryType::NonCacheable is the default memory type parameter, so just
stop requesting MemoryType::IO explicitly.
These changes were upstreamed by timschumi a few years ago. The patch
was dropped by doing:
```
$ ./package.sh dev
$ git am --skip # As there are no changes on the git tree.
$ exit
```
Previously, we attempted to print the device creation error. But device
creation should have already succeeded to reach this if statement, so
we would always crash if hub creation failed (.error() panics if it's
not an error).
In environments without any `SERENITY*` variables, grep returns an exit
status of 1. This patch ensures that the subcommand exits with status 0
regardless of whether grep finds a match. This prevents the script
from bailing out when `set -eo pipefail` is enabled.
Previously, only AArch64 used its "pretty" architecture name.
This matches other operating systems. Our own host architecture
detection code also only accepts "aarch64" and "arm64", not "AArch64".
I think matching the uname machine strings of other operating systems is
better than changing the other machine strings to "x86-64" and
"RISC-V 64" or "RV64I" (for RISC-V there isn't really an official
architecture name for the 64-bit variant except "RV64I").
Before the previous commit, these tests would result in an infinite
loop.
These test cases use small enough fractions to avoid the bug from
GitHub issue #26640. The default precision is 6, so this should be
printed as "10" both with correct and incorrect %g precision behavior.
Previously, small fractions that round to zero when converting them to
an integer would cause an infinite loop, since `ifraction % 10` is
always zero in that case.
When `ifraction` is zero, we don't need to print a fraction, so just
skip printing it.
These two lines seem unnecessary to boot on x86_64, aarch64 and riscv64.
It's not obvious to me why they were added in the first place (it was
in this commit: b5c98ede08).
