redox-os issueshttps://gitlab.redox-os.org/groups/redox-os/-/issues2024-02-28T11:40:43Zhttps://gitlab.redox-os.org/redox-os/netstack/-/issues/35Support promiscuous mode2024-02-28T11:40:43Zbjorn3Support promiscuous modeIn other word allow tools like wireshark to receive packets sent to a different application or even different computer (depending on the network connection mechanism used).In other word allow tools like wireshark to receive packets sent to a different application or even different computer (depending on the network connection mechanism used).https://gitlab.redox-os.org/redox-os/netstack/-/issues/34Support multiple network adapters at the same time2024-02-29T11:33:25Zbjorn3Support multiple network adapters at the same timehttps://gitlab.redox-os.org/redox-os/drivers/-/merge_requests/143 and https://gitlab.redox-os.org/redox-os/netstack/-/merge_requests/45 allow multiple network adapters to co-exist, but smolnetd will not actually use any beyond the first ...https://gitlab.redox-os.org/redox-os/drivers/-/merge_requests/143 and https://gitlab.redox-os.org/redox-os/netstack/-/merge_requests/45 allow multiple network adapters to co-exist, but smolnetd will not actually use any beyond the first yet.https://gitlab.redox-os.org/redox-os/ion_lsp/-/issues/4"Not", "and" and "or" builtin2024-02-26T08:31:23ZFlorian Naumann"Not", "and" and "or" builtinhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/191aarch64 float compile errors2024-02-21T00:44:20ZRon Williamsaarch64 float compile errorsA dev reported the following while compiling gettext.
```plaintext
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasnprintf.c:(.text+0x10e8): ...A dev reported the following while compiling gettext.
```plaintext
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasnprintf.c:(.text+0x10e8): undefined reference
to *
addtf3'
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasnprintf.c:(text+0x10f4): undefined reference
to ' fixtfsi'
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasprintf.c:(text+0x1100): undefined reference
to *
floatunsitf'
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasprintf.c:(.text+0x110c): undefined reference
to :
subtf3'
.....
```https://gitlab.redox-os.org/redox-os/ion_lsp/-/issues/1Find a tool to check for broken links in markdown files.2024-02-12T14:45:45ZFlorian NaumannFind a tool to check for broken links in markdown files.Personally I use a node application called [markdown-link-check](https://github.com/tcort/markdown-link-check) to check for broken links.
However I am reluctant to integrate into the official workflow of this project.
Reason: To check ...Personally I use a node application called [markdown-link-check](https://github.com/tcort/markdown-link-check) to check for broken links.
However I am reluctant to integrate into the official workflow of this project.
Reason: To check all files in the project, one needs to install this node application globally.
I like to have a tool which is built with cargo/rust.
I tried a rust tool called [mlc](https://github.com/becheran/mlc).
However I could not manage to filter out the markdowns file from the node modules in vs code extension.https://gitlab.redox-os.org/redox-os/bootloader/-/issues/8(Feature request) Save the default resolution in a configuration file, like GRUB2024-02-13T17:44:35ZRibbon(Feature request) Save the default resolution in a configuration file, like GRUBAdd a variable option in the configuration file to set a default resolution and ignore the resolution picker dialog.Add a variable option in the configuration file to set a default resolution and ignore the resolution picker dialog.https://gitlab.redox-os.org/redox-os/redox/-/issues/1430Orbital improvements2024-02-17T20:02:36ZRibbonOrbital improvementsThis tracking issue will cover the future Orbital desktop environment improvements.
- [ ] Serialize the Orbital settings to a TOML file (Orbital should watch for variable changes on this configuration file)
- [ ] Mimic the COSMIC Deskto...This tracking issue will cover the future Orbital desktop environment improvements.
- [ ] Serialize the Orbital settings to a TOML file (Orbital should watch for variable changes on this configuration file)
- [ ] Mimic the COSMIC Desktop top bar and dock design in the launcher
- [ ] Spawn two panels, one for the top panel and other for the dock
- [ ] Add a variable option to change the dock size
- [ ] Add a variable option to hide the window title bar if its maximized
- [ ] Add a variable option to change the Orbital wallpaper (use the image path)
- [ ] Add a variable option to change the top bar position (top, bottom, left, right)
- [ ] Add a variable option to change the dock position (top, bottom, left, right)
- [ ] Add a variable option to change the keyboard map (use ISO codes)
- [ ] Add a variable option to allow the dock to hide
- [ ] Add a variable option to disable the dock
- [ ] Add a variable option to disable the top bar (move all indicators and buttons to the end of the dock, like KDE Plasma does)
- [ ] Add a variable options to change the keyboard shortcuts
- [ ] Add a button in the dock to minimize all windows
- [ ] Add an top bar indicator to show the volume settings
- [ ] Add a way to mute the sound each program in the "Sound" indicator
- [ ] Add a top bar indicator button to disable/enable the Internet
- [ ] Add a "Restart" button on the App Menu and Login Manager
- [ ] Add a "Shutdown" button on the App Menu and Login Manager
- [ ] Add a "Lock Session" button on the App Menu
- [ ] Add a variable option to change the orblogin wallpaper
- [ ] Add a variable option to change the key repeat speed
- [ ] Add a variable option to change the mouse cursor speed
- [ ] Add a variable option to change the "running program" indicator color on the dock
- [ ] Add a variable option to change the top bar color (use color codes)
- [ ] Add a variable option to change the dock color (use color codes)
- [ ] Add a variable option to change the window title bar color
- [ ] Add a variable option to add a gap around the top bar (the edges will be rounded)
- [ ] Allow the reordering of pinned programs with mouse on the dock
- [ ] Port COSMIC Settingshttps://gitlab.redox-os.org/redox-os/redox/-/issues/1429GUI porting2024-02-10T17:16:57ZRibbonGUI portingThis issue will cover the porting of the most common rendering toolkits and libraries to Orbital.
- [ ] GLEW
- [ ] GTK3
- [ ] GTK4
- [ ] Qt5
- [ ] Qt6
- [ ] wxWidgetsThis issue will cover the porting of the most common rendering toolkits and libraries to Orbital.
- [ ] GLEW
- [ ] GTK3
- [ ] GTK4
- [ ] Qt5
- [ ] Qt6
- [ ] wxWidgetshttps://gitlab.redox-os.org/redox-os/nonprofit/-/issues/4Large Projects (> $150k)2024-02-09T20:01:20ZRon WilliamsLarge Projects (> $150k)To bid for certain large funds, we need to identify large projects with milestones and deliverables. The approach I would like to take for this is to identify "areas of work" that would each be done by one or two people. The grouping of ...To bid for certain large funds, we need to identify large projects with milestones and deliverables. The approach I would like to take for this is to identify "areas of work" that would each be done by one or two people. The grouping of work is in part to allow some specialization, so we can find full time staff that fits that profile. Here are some proposed projects.
* Redox cloud server - Hypervisor integration, device virtualization, web server support, NodeJS-style server, database support, server and container management
* PC Hardware compatibility - ACPI support, USB drivers, GPU/GPGPU acceleration, power management, etc., security mitigations for x86 and AMD CPUs
* OS Completeness and Performance Improvements - io_uring, openat, signals, End-to-end read/write performance, network performance
* Linux Graphics compatibility - Wayland, XWayland, GTK, Qt, Unix-domain sockets, various improvements to the graphics subsystem
* Compilers, Debuggers and Runtimes - Cargo, Rust, GNU Make, GNU Autotools, Automake, Java, GoLang, Python, C++, gdb, support libraries, symbol table tools, etc.
* Web browser and WASM support - Firefox, JavaScript, WebGL, WebAssembly, WASI and Rustix support
* Security and Survivability - Driver/daemon trust, partial failure detection and recovery, attack resistance, etc.https://gitlab.redox-os.org/redox-os/redox-path/-/issues/1Add more variants and parts to RedoxPath2024-01-28T06:23:38ZRon WilliamsAdd more variants and parts to RedoxPathProposed - Add the following variants to RedoxPath:
- Standard(RedoxReference) - a path that is absolute but has no scheme - interpreted as `/scheme/file/path`
- WithScheme(Scheme, RedoxReference) - a path with an explicit scheme
- Schem...Proposed - Add the following variants to RedoxPath:
- Standard(RedoxReference) - a path that is absolute but has no scheme - interpreted as `/scheme/file/path`
- WithScheme(Scheme, RedoxReference) - a path with an explicit scheme
- SchemeRoot - the literal path `/scheme`
This will help with stripping or adding `/scheme/file` as needed, and will simplify parsing the scheme (for the libc_scheme and Contain).https://gitlab.redox-os.org/redox-os/assets/-/issues/1Logo updates2024-01-27T23:23:14ZRon WilliamsLogo updatesWe need the following updates to the logo:
- The T-Shirt logos (black and white) are clipped at the right edge, so the S in OS is not completely round, this needs to be fixed
- The "logo" and "logo_small" logos are not the latest version...We need the following updates to the logo:
- The T-Shirt logos (black and white) are clipped at the right edge, so the S in OS is not completely round, this needs to be fixed
- The "logo" and "logo_small" logos are not the latest version of the logo and should be updated
- We need a dark mode (white on transparent) and a light mode (black on transparent) logo
- We need a non-transparent black-on-white logo
- There is a black and a white logo in the book that should be tracked in this repohttps://gitlab.redox-os.org/redox-os/relibc/-/issues/190Use a different format for passing argv/envp/auxv in execv2024-03-26T16:20:34ZJacob Lorentzon4ldo2@protonmail.comUse a different format for passing argv/envp/auxv in execvCurrently, Redox's execve implementation emulates Linux's format for passing the argv and envp pointers, and the auxiliary vectors, but this has several downsides. The current implementation does lots of mmap calls, which although it cou...Currently, Redox's execve implementation emulates Linux's format for passing the argv and envp pointers, and the auxiliary vectors, but this has several downsides. The current implementation does lots of mmap calls, which although it could be improved anyway, would be significantly easier with a simpler format. It also currently requires Redox-specific auxiliary vectors, which are passed null-terminated, which is true for envp too. The sigprocmask and "sigignmask" (POSIX requires execve to remember which signals were ignored, but otherwise reset them), as well as some internal relibc fds, would likely also need a custom auxv.
A simpler format would instead pass a header struct, providing the values the mandatory auxvs would otherwise provide, which might look like the following:
```rust
struct Header {
args_base: *const u8,
args_len: usize,
envs_base: *const u8,
envs_len: usize,
stack_top: *const u8,
stack_len: usize,
cwd_base: *const u8,
cwd_len: usize,
phnum: u16,
phentsize: u16,
page_size: u32,
phdr: u64,
procmask: u64, // set to "all blocked" until overridden by this value
ignmask: u64, // set to "all SIG_DFL" or "all SIG_IGN" until overridden by this value
interp_header: *const Header, // nullable
hwcap: u64,
}
```
It might also be possible for the args and envs to not be NUL-terminated, since relibc is forced to copy them anyway.https://gitlab.redox-os.org/redox-os/website/-/issues/196Website revamp 2024q12024-02-17T22:56:02ZJacob SchneiderWebsite revamp 2024q1## Near-Future TODOs
The following items need to be done in the very near future to keep the website fresh
- [ ] Switch to the full logo
- [ ] An _About the nonprofit_ section
- [ ] Allow very quick insertion of a _sponsors_ section
- [...## Near-Future TODOs
The following items need to be done in the very near future to keep the website fresh
- [ ] Switch to the full logo
- [ ] An _About the nonprofit_ section
- [ ] Allow very quick insertion of a _sponsors_ section
- [ ] Responsive design with reasonable max width
- [ ] Visual changes
- [ ] Content enhancements
- [ ] Add "Quick Links" or something similar on the home page for items that are moved out of the menu
## Constraints
- No JS
- Must work with Netsurf on Redox
## Distant TODOs
- [ ] Use @JCake's SSG
- [ ] Migrate content to new system
- [ ] Decide on long-term aesthetic styleJacob SchneiderJacob Schneiderhttps://gitlab.redox-os.org/redox-os/redoxer/-/issues/10Append instead of overwrite RUSTFLAGS2024-01-26T20:02:04Zbjorn3Append instead of overwrite RUSTFLAGSOtherwise it isn't possible for the user to pass custom rust flags.Otherwise it isn't possible for the user to pass custom rust flags.https://gitlab.redox-os.org/redox-os/kernel/-/issues/144Allow the kernel to log a panic message while the logger is still locked2024-02-27T10:44:41Zbjorn3Allow the kernel to log a panic message while the logger is still lockedNormally you can't log anything while the logger is locked to avoid multiple log messages from getting interleaved. When panicking the logger may never be unlocked as you may be panicking on the same kernel thread that holds the lock. Ge...Normally you can't log anything while the logger is locked to avoid multiple log messages from getting interleaved. When panicking the logger may never be unlocked as you may be panicking on the same kernel thread that holds the lock. Getting the panic message interleaved with other messages is much better than hanging without any panic message getting printed at all.https://gitlab.redox-os.org/redox-os/nonprofit/-/issues/2Intern Projects for GSoC or RSoC2024-01-26T18:38:41ZRon WilliamsIntern Projects for GSoC or RSoCFor GSoC, we should assume that our intern will have completed 3rd year undergrad, and who is a competent Rust programmer with some understanding of physical hardware, but may not have hands-on operating system experience. Project size s...For GSoC, we should assume that our intern will have completed 3rd year undergrad, and who is a competent Rust programmer with some understanding of physical hardware, but may not have hands-on operating system experience. Project size should be one of 90 hours (12 weeks spare time), 175 hours (12 weeks part time) or 350 hours (12 weeks full time). I think we should mainly request 350 hour projects, but Google is looking for us to request medium projects as well. We want projects that attract a range of interns, to engage the most competent (10x) people but not scare away people that are less experienced. Here are some suggestions. Feel free to edit or add here, use ~~strikethrough~~ to remove items.
GSoC recommends that the items be part of our regular suggestions to our contributors, so we should consider posting these projects on the CONTRIBUTING.md.
- Port a written-in-Rust web server to Redox. Get Redox to run in a VM (e.g. QEMU) on a cloud server, and enable Redox's website to be self-hosted. (low-hanging fruit, medium)
- Improve Redox's USB/HID support. (core, large)
- Help improve Redox's performance by developing end-to-end profiling tools and libraries, analyzing bottlenecks and helping implement optimizations. (exploratory, large)
- Implement "io_uring" for Redox's filesystem, RamFS and NVMe driver. (exploratory, large)
- Improve Redox's automated testing suite and continuous integration testing processes. (core, medium to large)
- Implement a user-space process manager that can safely modify process context information shared with the kernel. Implement the Session/Process Group/Process/Thread hierarchy. (exploratory, medium to large)
- Create a System Health profiling library, a GUI and a command-line interface to display activity levels for Redox's daemons and drivers. (peripheral, medium)
- Begin a port of WASM Rustix to Redox's written-in-Rust libc alternative, "relibc". Refactor relibc where needed to support both libc and Rustix interfaces. Implement additional functionality where feasible. (core, medium to large)
- Port a variety of Linux applications to Redox. This involves implementing functions in our libc alternative, "relibc" and possibly some GUI functionality. (core, medium to large)
- Perform a "survivability analysis" of Redox - What tasks can be killed and restarted, and still have Redox able to function? What will the effect on running applications be? What additional work needs to be done to improve survivability? Implement the proposed functionality and tooling. (exploratory, medium to large)https://gitlab.redox-os.org/redox-os/bootstrap/-/issues/1Link with relibc rather than using redox-exec directly2024-01-21T12:41:00ZJacob Lorentzon4ldo2@protonmail.comLink with relibc rather than using redox-exec directlyThis would simplify relibc's exec implementation significantly. Bootstrap would initialize an environment similar enough that it can call relibc_start directly, and continue running in `main`.This would simplify relibc's exec implementation significantly. Bootstrap would initialize an environment similar enough that it can call relibc_start directly, and continue running in `main`.https://gitlab.redox-os.org/redox-os/event/-/issues/3Feature: non-blocking event interface2024-01-17T18:44:58ZRon WilliamsFeature: non-blocking event interfaceA non-blocking event interface is required so applications can ensure all pending events have been addressed before returning. This is required by e.g. `epoll`.
Two possible implementations:
- `maybe_next` (or other name) would perform ...A non-blocking event interface is required so applications can ensure all pending events have been addressed before returning. This is required by e.g. `epoll`.
Two possible implementations:
- `maybe_next` (or other name) would perform a non-blocking check for events. The implementation could turn blocking off and then on, so that `next` continues to be blocking. Or the implementation could maintain state indicating if it is in blocking mode, and turn it on/off as required.
- `has_event` would maintain an event queue internally, reading up to the maximum number events (based on registered fds) whenever it blocks, and `has_event` would indicate if the event queue is empty.https://gitlab.redox-os.org/redox-os/event/-/issues/2Feature: Timeout2024-01-17T12:33:06ZRon WilliamsFeature: TimeoutSince many of the uses of the `redox_event` crate include timeout handling (it's often the only reason event multiplexing is required), it is proposed that a "timeout" interface be added to `redox_event`. Details TBD, but probably it sho...Since many of the uses of the `redox_event` crate include timeout handling (it's often the only reason event multiplexing is required), it is proposed that a "timeout" interface be added to `redox_event`. Details TBD, but probably it should just be an event with user_data indicating it's a timer event.https://gitlab.redox-os.org/redox-os/redox/-/issues/1428Rework the graphics handling2024-02-13T17:44:36Zbjorn3Rework the graphics handling* [x] Move text console support out of vesad to allow other graphics drivers to reuse it. (https://gitlab.redox-os.org/redox-os/drivers/-/merge_requests/128)
* [ ] Better IPC serialization/deserialization. The current ad-hoc code is erro...* [x] Move text console support out of vesad to allow other graphics drivers to reuse it. (https://gitlab.redox-os.org/redox-os/drivers/-/merge_requests/128)
* [ ] Better IPC serialization/deserialization. The current ad-hoc code is error prone and hard to keep in sync between components as you need to change everything in lockstep. Something like [Cap'n Proto](https://capnproto.org/) ([Rust implementation](https://github.com/capnproto/capnproto-rust)) may be a better fit. It should allow keeping compatibility with older programs even when we add and remove commands.
* [ ] Move the console multiplexing out of the individual graphics drivers. Instead have a protocol that allows swapping the framebuffer to be rendered by the graphics driver and then have an fbmuxd daemon which saves the current framebuffer for every virtual terminal and tells the graphics driver to swap it out whenever either switching between vt's or when the client requests the framebuffer to be swapped. The vga/vesa driver can then write it to the actual framebuffer while the virtio-gpu driver in the future could request the virtio-gpu device to change which framebuffer to use for scanout once it becomes possible for users to directly create buffers on the gpu. Fbmuxd would also handle multiplexing of input devices.
* [ ] Support for hardware backed cursor. This both decreases latency and improves energy efficiency by offloading rendering of the cursor to the display controller (on mobile devices this is an entirely separate part of the SoC by the way). Not every gpu and gpu interfaces support this though. VGA doesn't support it, but virtio-gpu does and so do all desktop gpu's.
* [ ] Allow delegating control over a virtual terminal to a different program. This would allow for example the login screen to delegate control to an instance of orbital running as the logged in user, reducing attack surface. Or for a VR game to get full control over page flipping and mode setting. It should also be possible for the delegating program to revoke access again for all the (in)directly delegated programs. This delegation should happen for both the display and input devices. Preferrably with an option for the delegating program to keep accepting input such that it can for example listen for Super+L to lock the screen and show a password prompt for the current user.
* [ ] Support mode setting. That is changing display resolutions, display mirroring, selecting which part of a buffer to show, using multiple planes aside from the hardware backed cursor.
* [ ] Allow creating buffers on the gpu and running commands like shader invocations on them. Initially just virgl (OpenGL) or venus (Vulkan) support for virtio-gpu would work. This final step would allow actual hardware acceleration.