redox-os issueshttps://gitlab.redox-os.org/groups/redox-os/-/issues2024-03-28T17:29:38Zhttps://gitlab.redox-os.org/redox-os/libredox/-/issues/4Split off libredox implementation from relibc2024-03-28T17:29:38ZJacob Lorentzon4ldo2@protonmail.comSplit off libredox implementation from relibcThe libredox symbols could be moved to e.g. `libsystem.so` or `libsystem.a`, independent of relibc. Ideally, such a library should be self-sufficient for running Rust applications.The libredox symbols could be moved to e.g. `libsystem.so` or `libsystem.a`, independent of relibc. Ideally, such a library should be self-sufficient for running Rust applications.https://gitlab.redox-os.org/redox-os/libredox/-/issues/3Futex2024-03-28T11:09:43ZJacob Lorentzon4ldo2@protonmail.comFutexAlthough parking_lot_core shortcuts to the unix path, away from using redox_syscall, it should still be rewritten to use libredox. Libredox thus needs APIs for futex support. Suggested APIs:
```ruts
fn redox_futex_wait32_v1(word: *const...Although parking_lot_core shortcuts to the unix path, away from using redox_syscall, it should still be rewritten to use libredox. Libredox thus needs APIs for futex support. Suggested APIs:
```ruts
fn redox_futex_wait32_v1(word: *const i32, expected: i32, timeout: nullable *const TimeSpec) -> RawResult;
fn redox_futex_wake32_v1(word: *const i32, num_wake: i32) -> RawResult;
// TODO: requeue
```
The reason to suffix both of these with "32", is because it might be useful to implement address or value masking in the future, and because a hash table could be more efficient the more address bits are available due to alignment.
However, Linux's futex syscall has several limitations, such as only being able to wait on one value, and being limited to 32 bits, which explains futex_v2. It might also be useful to implement futexes in userspace, similar to parking_lot_core itself, using an underlying semi-atomic hash table (e.g. lock-free unless shrinking), and a similar "wait for thread" syscall. That said, that probablyhttps://gitlab.redox-os.org/redox-os/cookbook/-/issues/198Packagers list2024-03-27T18:03:01ZRibbonPackagers listThis issue covers our current packagers.
- [Jeremy Soller](https://gitlab.redox-os.org/jackpot51)
- [Ribbon](https://gitlab.redox-os.org/hatred_45)
- [Ron Williams](https://gitlab.redox-os.org/rw_van)
- [Bendeguz Pisch](https://gitlab.r...This issue covers our current packagers.
- [Jeremy Soller](https://gitlab.redox-os.org/jackpot51)
- [Ribbon](https://gitlab.redox-os.org/hatred_45)
- [Ron Williams](https://gitlab.redox-os.org/rw_van)
- [Bendeguz Pisch](https://gitlab.redox-os.org/bpisch)
- [Chocimier](https://gitlab.redox-os.org/Chocimier)https://gitlab.redox-os.org/redox-os/cookbook/-/issues/197Trigger recipe relink when relibc changes2024-03-26T21:28:57ZRibbonTrigger recipe relink when relibc changesCurrently the build system don't trigger a relink of all enabled recipes when the relibc submodule changes (new commit hash), this make the recipes use the old version of the relibc object and don't apply new fixes or improvements.
The ...Currently the build system don't trigger a relink of all enabled recipes when the relibc submodule changes (new commit hash), this make the recipes use the old version of the relibc object and don't apply new fixes or improvements.
The proposal is to trigger a fast relink of Rust-written recipes (ideally only the relibc object) and clean + rebuild C/C++ written recipes when the relibc submodule changes the pinned commit hash.https://gitlab.redox-os.org/redox-os/relibc/-/issues/192Implement posix_spawn2024-03-26T16:24:46ZJacob Lorentzon4ldo2@protonmail.comImplement posix_spawnSince Redox's `execv*` and `fork` implementations are based on the lower-level kernel context handles, it would be preferable to provide a custom implementation of `posix_spawn{,p}`, using those native APIs. The API in `redox-exec` alrea...Since Redox's `execv*` and `fork` implementations are based on the lower-level kernel context handles, it would be preferable to provide a custom implementation of `posix_spawn{,p}`, using those native APIs. The API in `redox-exec` already supports executing a remote process, which could be combined with the fork API, minus the copy-everything-and-then-reinitialize-everything parts.https://gitlab.redox-os.org/redox-os/redox/-/issues/1435Add driver customization2024-03-26T06:13:11ZRibbonAdd driver customizationDrivers are the most big part of an operating system and the average computer only use some of them.
This proposal is to add or remove individual drivers from a filesystem image (`config/*.toml`) by using this syntax:
```toml
[drivers]...Drivers are the most big part of an operating system and the average computer only use some of them.
This proposal is to add or remove individual drivers from a filesystem image (`config/*.toml`) by using this syntax:
```toml
[drivers] # A new section for driver entries
driver1 = {}
driver2 = {}
#driver3 = {} # Disabled driver
driver4 = "none" # Another way to disable a driver (if necessary)
```https://gitlab.redox-os.org/redox-os/acid/-/issues/1Test fmap and funmap overlapping partially with an existing mapping2024-03-18T10:03:35Zbjorn3Test fmap and funmap overlapping partially with an existing mappingTo catch bugs like the one fixed in https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/286.To catch bugs like the one fixed in https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/286.https://gitlab.redox-os.org/redox-os/drivers/-/issues/40Community hardware device porting2024-03-17T23:48:03ZRibbonCommunity hardware device portingThis tracking issue covers the devices from the community that needs a driver.
Unfortunately we can't know the most sold device models of the world to measure our device porting priority, thus we will use our community data to measure o...This tracking issue covers the devices from the community that needs a driver.
Unfortunately we can't know the most sold device models of the world to measure our device porting priority, thus we will use our community data to measure our device priorities, if you find a "device model users" survey (similar to [Debian Popularity Contest](https://popcon.debian.org/) and [Steam Hardware/Software Survey](https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam)), please comment.
If you want to contribute to this table, install [pciutils](https://mj.ucw.cz/sw/pciutils/) on your Linux (it should have a package on your distribution), run `lspci -v` to see your hardware devices and their kernel drivers and give the results of these items on each device:
- The first field (each device has an unique name for this item)
- Kernel driver in use
- Kernel modules
If you are unsure of what to do, you can copy and paste the entire text to a code block and comment.
| **Device model** | **Kernel driver** | **Kernel module** | **There's a Redox driver?** |
|------------------|-------------------|-------------------|-----------------------------|
| Realtek RTL8821CE 802.11ac (Wi-Fi) | rtw_8821ce | rtw88_8821ce | No |
| Intel Ice Lake-LP SPI Controller | intel-spi | spi_intel_pci | No |
| Intel Ice Lake-LP SMBus Controller | i801_smbus | i2c_i801 | No |
| Intel Ice Lake-LP Smart Sound Technology Audio Controller | snd_hda_intel | snd_hda_intel, snd_sof_pci_intel_icl | No |
| Intel Ice Lake-LP Serial IO SPI Controller | intel-lpss | No | No |
| Intel Ice Lake-LP Serial IO UART Controller | intel-lpss | No | No |
| Intel Ice Lake-LP Serial IO I2C Controller | intel-lpss | No | No |
| Ice Lake-LP USB 3.1 xHCI Host Controller | xhci_hcd | No | No |
| Intel Processor Power and Thermal Controller | proc_thermal | processor_thermal_device_pci_legacy | No |
| Intel Device 8a02 | icl_uncore | No | No |
| Iris Plus Graphics G1 (Ice Lake) | i915 | i915 | No |https://gitlab.redox-os.org/redox-os/kernel/-/issues/148Support generic interrupts on arm642024-03-17T20:29:57Zbjorn3Support generic interrupts on arm64See the thread starting at https://matrix.to/#/%23redox-dev%3Amatrix.org/%24hVX4XI4x2tbwbJCSl1vQ5wx0C7GOBNGfWTmXAtW6e3c?via=mozilla.org&via=matrix.org&via=artifact8.xyz&via=envs.net But basically only timer and serial interrupts currentl...See the thread starting at https://matrix.to/#/%23redox-dev%3Amatrix.org/%24hVX4XI4x2tbwbJCSl1vQ5wx0C7GOBNGfWTmXAtW6e3c?via=mozilla.org&via=matrix.org&via=artifact8.xyz&via=envs.net But basically only timer and serial interrupts currently work. The `irq:` scheme required by most PCI drivers (and other drivers) is non-functional. This needs to be implemented for each of the three irq chips supported by the kernel.https://gitlab.redox-os.org/redox-os/kernel/-/issues/147Support huge pages2024-03-16T10:21:13ZJacob Lorentzon4ldo2@protonmail.comSupport huge pagesHuge pages are heavier, slower to CoW, and possibly wasting memory, and would waste 0.4% being unused `PageInfo`s. But they do almost always reduce TLB overhead, and most importantly, they require far less page table mappings and flushes...Huge pages are heavier, slower to CoW, and possibly wasting memory, and would waste 0.4% being unused `PageInfo`s. But they do almost always reduce TLB overhead, and most importantly, they require far less page table mappings and flushes than small pages. That means they can potentially, in some cases, be a huge improvement (512x for 2 MiB pages) in IPC latency and to a lesser extent, throughput. 1 GiB pages may also allow (recently-used) physical addresses to hopefully always reside in at least the L2DTLB in kernel mode, speeding up e.g. copying of pages. Jeremy measured the optimal buffer size for throughput, (for most schemes including redoxfs), was 4 MiB, with larger sizes being slower due to mapping/flushing and possibly TLB overhead.
Worth noting AArch64 supports two additional standard page sizes -- 16 KiB and 64 KiB, which for some if not most workloads is more efficient, and 16k could maybe even be a better default. Ironically, Zen3+ AMD CPUs also support a 16 KiB page size, by merging any 4 virtually-contiguous pages that are physically contiguous and naturally 16k-aligned, into a single 16 KiB TLB entry. Although it would waste 4x as much page table memory, that might also be worth looking into.https://gitlab.redox-os.org/redox-os/kernel/-/issues/146Implement CPU softlockup and hardlockup detection2024-03-15T14:17:19ZRibbonImplement CPU softlockup and hardlockup detectionhttps://www.kernel.org/doc/html/latest/admin-guide/lockup-watchdogs.htmlhttps://www.kernel.org/doc/html/latest/admin-guide/lockup-watchdogs.htmlhttps://gitlab.redox-os.org/redox-os/uutils/-/issues/6whoami not working for non-root user2024-03-15T04:37:42ZRon Williamswhoami not working for non-root userhttps://gitlab.redox-os.org/redox-os/uutils/-/issues/5df not working correctly2024-03-15T03:38:04ZRon Williamsdf not working correctlyAfter the change to RedoxFS to add records, df is not working correctly.After the change to RedoxFS to add records, df is not working correctly.https://gitlab.redox-os.org/redox-os/redox-initfs/-/issues/2Add file entry for the bootstrap code to the initfs2024-03-26T17:49:14Zbjorn3Add file entry for the bootstrap code to the initfsThis can be useful for debugging purposes.This can be useful for debugging purposes.https://gitlab.redox-os.org/redox-os/kernel/-/issues/145Support process-context identifiers2024-03-11T15:24:56ZJacob Lorentzon4ldo2@protonmail.comSupport process-context identifiersPage table switching is a significant part of context switch overhead, which process-context identifiers help reduce. With [TLB shootdown](https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/282) now properly implemented, it wou...Page table switching is a significant part of context switch overhead, which process-context identifiers help reduce. With [TLB shootdown](https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/282) now properly implemented, it would be a natural extension to add a percpu queue of `Weak<AddrSpaceWrapper>`, and retain the address space CPU users bits set as long as they are still in that queue. PCIDs would only be used for userspace mappings, as the redox kernel memory layout makes a clear distinction between user and kernel addresses. An address space is user-accessible if and only if it's lower half, and if and only if it's non-Global.
Because this may impact TLB shootdown performance, it would need to be benchmarked thoroughly before being enabled at least by default.https://gitlab.redox-os.org/redox-os/cookbook/-/issues/196Build shared objects in some recipes2024-03-11T14:19:57ZRibbonBuild shared objects in some recipesTo enforce our [package size policy](https://gitlab.redox-os.org/redox-os/cookbook#library-linking) we need to make the bigger libraries build shared objects for dynamic linking.
(If you find other dependencies bigger than 20MB, comment...To enforce our [package size policy](https://gitlab.redox-os.org/redox-os/cookbook#library-linking) we need to make the bigger libraries build shared objects for dynamic linking.
(If you find other dependencies bigger than 20MB, comment on this issue)
- [ ] llvm - Most big dependency
- [ ] ffmpeg6
- [ ] gstreamer
- [ ] boosthttps://gitlab.redox-os.org/redox-os/mesa/-/issues/1Update the patches with the current upstream code2024-03-01T20:15:03ZRibbonUpdate the patches with the current upstream codehttps://gitlab.redox-os.org/redox-os/redox/-/issues/1433Port OpenSSL 32024-03-01T20:09:13ZRibbonPort OpenSSL 3It's necessary to run many programs.It's necessary to run many programs.https://gitlab.redox-os.org/redox-os/redox/-/issues/1432Making Cosmic Edit and File Manager the defaults2024-03-01T19:56:31ZRon WilliamsMaking Cosmic Edit and File Manager the defaultsTo make Cosmic Edit and File Manager the defaults in Orbital, a little bit of work is required.
- [ ] Decide if we will drop Orbital Edit and File Manager or if we want to keep them as an option.
- [ ] If we want to keep them, we will n...To make Cosmic Edit and File Manager the defaults in Orbital, a little bit of work is required.
- [ ] Decide if we will drop Orbital Edit and File Manager or if we want to keep them as an option.
- [ ] If we want to keep them, we will need a orbdata-cosmic recipe that will replace orbdata. If we will drop them, then we can just update orbdata. Alternatively, we could remove the `launcher` data for the OrbUtils versions from orbdata, and have the `launcher` data defined in the configuration file.
- [ ] Make a recipe for orbutils-extras that only builds the orbutils we need to add when using Cosmic apps.
- [ ] If we will drop Orbital Edit and File Manager, then we should modify `config/desktop.toml` to add the Cosmic apps and drop the Orbital versions. If we will keep them, we need two versions of `desktop.toml`, one for orbutils and one for Cosmic.
- [ ] It would be nice if all the parts of the Cosmic desktop were defined in one config file, for clarity. That file would then be included by the `desktop.toml` config file.https://gitlab.redox-os.org/redox-os/redox/-/issues/1431Tracking Issue for UNIX-style paths2024-03-01T13:39:43ZRon WilliamsTracking Issue for UNIX-style pathsThe following is a list of changes to made to complete the implementation of the new path format.
- [ ] Update the documentation to use the new format wherever possible but describe the legacy format and say it is still used
- [ ] Final...The following is a list of changes to made to complete the implementation of the new path format.
- [ ] Update the documentation to use the new format wherever possible but describe the legacy format and say it is still used
- [ ] Finalize the [namespace RFC](https://gitlab.redox-os.org/redox-os/rfcs/-/merge_requests/20 "Add RFC for the namespace root.")
- [ ] Decide when `/scheme/file` should be explicit and when it should be removed/hidden
- [ ] Convert relibc to the new path format (this should have it's own tracking issue)
- [ ] Finish converting the kernel to the new path format everywhere
- [ ] Implement the namespace RFC in the kernel with support for both current and new formats
- [ ] Stablize the redox-scheme crate and redox-event crate and update to the new format for paths and namespace
- [ ] Convert all schemes and drivers to use redox-scheme and redox-event rather than creating sockets directly (this should have its own tracking issue)
- [ ] Decide on Orbital paths and get/set window attributes (may need its own RFC)
- [ ] Convert OrbUtils and other Orbital-compatible programs to use the new Orbital path format
- [ ] Wrap all legacy format support (and conversion between formats) with a feature guard going forward
- [ ] Add the feature guard to the kernel, relibc, RedoxFS and anything else that supports both formats
- [ ] Convert all libraries to the new format (or to handle both formats if appropriate) (this should have its own tracking issue)
- [ ] Convert all programs to the new format (this should have its own tracking issue)
- [ ] Disable the legacy format feature guard in each program and test
- [ ] Remove all guarded legacy format support
- [ ] Update the documentation to remove all references to the old format