Tracking Issue for multidep #10030
Labels
C-tracking-issue
Category: A tracking issue for something unstable.
S-needs-mentor
Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.
Projects
Comments
ehuss
added
the
C-tracking-issue
5 tasks
kevinaboos
added a commit
to theseus-os/Theseus
that referenced
this issue
Jan 12, 2023
* Removes old assumptions/requirements that all sections
in the kernel base image are loaded into physically-contiguous
memory, especially the stack and bootloader info.
* IOW, we stop relying upon a fixed `KERNEL_OFFSET` to
calculate virtual addresses from physical addresses and vice versa;
instead, we actually translate addresses via the initial page table.
* Thus, we must obtain the address of the GDT used to boot
secondary CPUs (APs on x86) and pass it through the various
init routines so that it can be used when booting secondary CPUs.
* `PageRange` and `FrameRange` constructors will now return an
empty range if invoked with a size of 0 bytes, instead of panicking.
* The major changes in this commit is to introduce new crates that
support building Theseus for and booting it on UEFI bootloaders.
* `tools/uefi-builder` is now multi-architecture,
but aarch64 support is a WIP.
* The separate `theseus-os/uefi-bootloader` repo is a fork of
`rust-osdev/bootloader` but heavily changed to support Theseus's
needs and additional architectures.
* aarch64 is still a WIP here too.
* Currently we manually ensure that the same version of the
`uefi-bootloader*` crates are used in the Theseus workspace
and in the `tools/uefi-builder/*` crates. Ideally this would be
ensured automatically in the future.
* `uefi-builder` consists of separate, per-arch crates; we can combine
them once <rust-lang/cargo#10030> is fixed.
Co-authored-by: Kevin Boos <kevinaboos@gmail.com>
github-actions bot
pushed a commit
to theseus-os/Theseus
that referenced
this issue
Jan 12, 2023
* Removes old assumptions/requirements that all sections
in the kernel base image are loaded into physically-contiguous
memory, especially the stack and bootloader info.
* IOW, we stop relying upon a fixed `KERNEL_OFFSET` to
calculate virtual addresses from physical addresses and vice versa;
instead, we actually translate addresses via the initial page table.
* Thus, we must obtain the address of the GDT used to boot
secondary CPUs (APs on x86) and pass it through the various
init routines so that it can be used when booting secondary CPUs.
* `PageRange` and `FrameRange` constructors will now return an
empty range if invoked with a size of 0 bytes, instead of panicking.
* The major changes in this commit is to introduce new crates that
support building Theseus for and booting it on UEFI bootloaders.
* `tools/uefi-builder` is now multi-architecture,
but aarch64 support is a WIP.
* The separate `theseus-os/uefi-bootloader` repo is a fork of
`rust-osdev/bootloader` but heavily changed to support Theseus's
needs and additional architectures.
* aarch64 is still a WIP here too.
* Currently we manually ensure that the same version of the
`uefi-bootloader*` crates are used in the Theseus workspace
and in the `tools/uefi-builder/*` crates. Ideally this would be
ensured automatically in the future.
* `uefi-builder` consists of separate, per-arch crates; we can combine
them once <rust-lang/cargo#10030> is fixed.
Co-authored-by: Kevin Boos <kevinaboos@gmail.com> 922cb09
github-actions bot
pushed a commit
to tsoutsman/Theseus
that referenced
this issue
Jan 12, 2023
* Removes old assumptions/requirements that all sections
in the kernel base image are loaded into physically-contiguous
memory, especially the stack and bootloader info.
* IOW, we stop relying upon a fixed `KERNEL_OFFSET` to
calculate virtual addresses from physical addresses and vice versa;
instead, we actually translate addresses via the initial page table.
* Thus, we must obtain the address of the GDT used to boot
secondary CPUs (APs on x86) and pass it through the various
init routines so that it can be used when booting secondary CPUs.
* `PageRange` and `FrameRange` constructors will now return an
empty range if invoked with a size of 0 bytes, instead of panicking.
* The major changes in this commit is to introduce new crates that
support building Theseus for and booting it on UEFI bootloaders.
* `tools/uefi-builder` is now multi-architecture,
but aarch64 support is a WIP.
* The separate `theseus-os/uefi-bootloader` repo is a fork of
`rust-osdev/bootloader` but heavily changed to support Theseus's
needs and additional architectures.
* aarch64 is still a WIP here too.
* Currently we manually ensure that the same version of the
`uefi-bootloader*` crates are used in the Theseus workspace
and in the `tools/uefi-builder/*` crates. Ideally this would be
ensured automatically in the future.
* `uefi-builder` consists of separate, per-arch crates; we can combine
them once <rust-lang/cargo#10030> is fixed.
Co-authored-by: Kevin Boos <kevinaboos@gmail.com> 922cb09
ehuss
added
the
S-needs-mentor
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
RFC: #3176
This is the tracking issue for RFC 3176 which extends Cargo to allow depending on the same crate multiple times with different dependency names, to support artifact dependencies for multiple targets.
This is a follow up to RFC #3028 tracking issue #9096.
Unresolved Issues
No response
Future Extensions
No response
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
The text was updated successfully, but these errors were encountered: