redox-os issueshttps://gitlab.redox-os.org/groups/redox-os/-/issues2018-06-15T11:40:04Zhttps://gitlab.redox-os.org/redox-os/redox/-/issues/143What is the point of Building in ${DISTRONAME} Linux in Readme?2018-06-15T11:40:04ZJeremy SollerWhat is the point of Building in ${DISTRONAME} Linux in Readme?*Created by: cnd*
looks like Building part and Installing part there are same for all distributions
is it for planned documentation about getting dependencies?
*Created by: cnd*
looks like Building part and Installing part there are same for all distributions
is it for planned documentation about getting dependencies?
https://gitlab.redox-os.org/redox-os/redox/-/issues/145Partial redraws2018-06-15T11:40:04ZJeremy SollerPartial redraws*Created by: ticki*
Full screen redraws are very expensive. Why not use partial redraws?
*Created by: ticki*
Full screen redraws are very expensive. Why not use partial redraws?
https://gitlab.redox-os.org/redox-os/redox/-/issues/146[BUG] redox::orbital::Window::poll() returns the same event multiple times in...2018-06-15T11:40:04ZJeremy Soller[BUG] redox::orbital::Window::poll() returns the same event multiple times in some cases.*Created by: ticki*
*Created by: ticki*
https://gitlab.redox-os.org/redox-os/redox/-/issues/147KeyEvent::from_event().character is '\0' when it actually should be a unicode...2018-06-15T11:40:04ZJeremy SollerKeyEvent::from_event().character is '\0' when it actually should be a unicode input code.*Created by: ticki*
Backspace -> '\0', even though it should be '\u{0008}'
Shift -> '\0', even though it should be '\u{000E}'.
etc.
*Created by: ticki*
Backspace -> '\0', even though it should be '\u{0008}'
Shift -> '\0', even though it should be '\u{000E}'.
etc.
https://gitlab.redox-os.org/redox-os/redox/-/issues/149Support green threads2018-06-15T11:40:04ZJeremy SollerSupport green threads*Created by: zonyitoo*
Rust does not support green threads officially, and the `std::io` and `std::net` are built for blocking I/O. But green threads should be an implementation detail, so it is possible to just switch the `libstd` (let...*Created by: zonyitoo*
Rust does not support green threads officially, and the `std::io` and `std::net` are built for blocking I/O. But green threads should be an implementation detail, so it is possible to just switch the `libstd` (let `rustc` link another `libstd`) and make it uses green threads under the hood. Then that Rust application will run with green threads without modifying anything.
Green threads are very helpful to build I/O bound applications, such as servers. Although you can always build an application by writing a state machine, or using callback style APIs. But the first method is hard to manage and it is not an easy job to do it well, and the second one will cause callback hell, your code will be teared apart into small pieces.
Green threads will not help to boost performance, but it is very helpful to build an I/O bound application. The simplest server model is one thread per connection. But because of using native threads are too heavy, we cannot do that in almost all realistic use cases, and green threads could help to solve this problem instead.
Things need to be done in the kernel:
1. Non-blocking I/O, including async file I/O and non-blocking socket I/O. It would be better if they have unified APIs.
2. I/O multiplexer (Eventloop). Something like Epoll, Kqueue or IOCP.
Things need to be done in the user-space:
1. Basic supports of green threads, including context-switch, channels (lock-free queues), Mutex, Condvar, `thread_local` (green thread local) and the others.
2. Green threads' non-preemptive scheduler. This scheduler should be able to use multiple CPU cores with M:N model.
3. A special version of `libstd`, which will make all I/O calls to be handled by the green thread library. `thread::spawn` will spawn a green thread instead of a native thread.
https://gitlab.redox-os.org/redox-os/redox/-/issues/150Getting started with redox-os2018-06-15T11:40:04ZJeremy SollerGetting started with redox-os*Created by: NobbZ*
Since I wanted to contribute somehow as a practical sideproject to the upcomming "building operating systems"-lectures this semester, I wanted to checkout redox-os, take a look at it, play around and perhaps contribu...*Created by: NobbZ*
Since I wanted to contribute somehow as a practical sideproject to the upcomming "building operating systems"-lectures this semester, I wanted to checkout redox-os, take a look at it, play around and perhaps contribute.
But one of the biggest problems is the following:
After building with `windows/make all` and then starting with `windows/make virtualbox` I do only see the following in my VirtualBox:
![redox-desktop](https://cloud.githubusercontent.com/assets/58951/10564511/a0dd685a-75b7-11e5-8741-beb12a610bd5.png)
When I hit CTRL-F1, I come back to the startup output and see the following content:
![redox-bootscreen](https://cloud.githubusercontent.com/assets/58951/10564515/bad973a2-75b7-11e5-8a51-6df95ad789fa.png)
From the first screen, I can move the mouse around, but nothing else happens, even after an hour of waiting. How can I get at least to the stage of a usable desktop as shown in the Screenshot from the README.md?
![https://github.com/redox-os/redox/raw/master/img/screenshots/Desktop.png](https://github.com/redox-os/redox/raw/master/img/screenshots/Desktop.png)
https://gitlab.redox-os.org/redox-os/redox/-/issues/164Program arguments are not handled correctly2018-06-15T11:40:04ZJeremy SollerProgram arguments are not handled correctly*Created by: stratact*
Currently `redox::env::args()` doesn't work correctly. It requires the new rustc attribute `#[naked]` which was just recently added to rust-lang/rust in a PR. We need to address the functions that do not have stan...*Created by: stratact*
Currently `redox::env::args()` doesn't work correctly. It requires the new rustc attribute `#[naked]` which was just recently added to rust-lang/rust in a PR. We need to address the functions that do not have standard wrappers, like stack frames, local variables, or a function return. Without this, the arguments passed to the `App::main()` method calls will not parse correctly and will hit `None` while trying to match, causing inconsistent behaviour.
https://gitlab.redox-os.org/redox-os/redox/-/issues/165build fails on Mac OS X El Capitan2018-06-15T11:40:04ZJeremy Sollerbuild fails on Mac OS X El Capitan*Created by: sumproxy*
Here's the output log:
```
mkdir -p build/x86_64
rustc --target=x86_64-unknown-redox.json -C no-prepopulate-passes -C no-vectorize-loops -C no-vectorize-slp -C no-stack-check -C opt-level=2 -Z no-landing-pads -A ...*Created by: sumproxy*
Here's the output log:
```
mkdir -p build/x86_64
rustc --target=x86_64-unknown-redox.json -C no-prepopulate-passes -C no-vectorize-loops -C no-vectorize-slp -C no-stack-check -C opt-level=2 -Z no-landing-pads -A dead-code -A deprecated -L build/x86_64 -C ar=x86_64-elf-ar -C linker=x86_64-elf-linker -o build/x86_64/libcore.rlib rust/libcore/lib.rs
error: could not exec `x86_64-elf-ar`: No such file or directory (os error 2)
make: *** [build/x86_64/libcore.rlib] Error 101
```
https://gitlab.redox-os.org/redox-os/redox/-/issues/172A proposal for Redox configuration system2023-06-13T04:29:01ZJeremy SollerA proposal for Redox configuration system*Created by: tennix*
Traditional *nix system has config files everywhere and in different formats. That's a headache for users. For simplicity I think Redox should have a central place to store configs and in a transparent format, that ...*Created by: tennix*
Traditional *nix system has config files everywhere and in different formats. That's a headache for users. For simplicity I think Redox should have a central place to store configs and in a transparent format, that is it should be easy for users to find their configs and read/write easily without special tools.
Due to everything is a URL in Redox, and inspired by [Etcd](https://github.com/coreos/etcd). I think Redox can have following URLs to config the whole system.
system config `config://pkg-name/version/system/key/value`
user config `config://pkg-name/version/username/key/value`
for example _git_ config should be organized as following:
```
config://git/2.3.8/system/core.editor/vim
config://git/2.3.8/tennix/core.editor/emacs
```
That way it's easy to read and set a configuration item. For example if we serve configs as http resource, we can use curl to get and set an item just like in etcd.
But the problem is that we can no longer comment our configurations for documentation purpose.
For this we have two solutions:
- make doc as a key in configuration
```
config://pkg-name/version/system/doc/index.html
config://pkg-name/version/username/doc/index.html
```
- make doc as a new scheme
```
doc://pkg-name/version/system/index.html
doc://pkg-name/version/username/index.html
```
Either way docs are normal text files but rendered as html for better read. Redox can provide some basic converters to convert common markup doc like rst/md to html, and users can provide their own doc converters if needed.
Since everything is URL, we can easily get all configurations and render them in a webpage. And what's more, we can even config our system in a web browser just like Firefox's _about://config_ and Chrome's _chrome://settings_
For compatibility with current *nix software, we can map these urls to their current file config. Or just specify the config file path as a key in the url like `config://git/2.3.8/tennix/configpath//home/tennix/.gitconfig`
Of course the file path `/home/tennix/.gitconfig` should be encoded as safe url here, but that's not the main point here.
Besides with proper permissions, we can share our configuration to others. And if we want, we can even import other systems' configuration in the same network. Just like mount a remote filesystem to local machine, we "mount" remote system's settings as local settings.
Some problems:
- How to sync comment with config?
- A proper permission model
- ...
https://gitlab.redox-os.org/redox-os/redox/-/issues/175A proposal for URL replacement2018-06-15T11:40:04ZJeremy SollerA proposal for URL replacement*Created by: zonyitoo*
Redox uses URL as resource locator, which makes it outstanding from the other OS that written in pure Rust. But the URL in Redox has the following syntax
```
scheme://nomatterwhatgoeshere
```
The content after `...*Created by: zonyitoo*
Redox uses URL as resource locator, which makes it outstanding from the other OS that written in pure Rust. But the URL in Redox has the following syntax
```
scheme://nomatterwhatgoeshere
```
The content after `:` will all be processed by the `scheme`, so it is not actually a valid [IANA URI](http://tools.ietf.org/html/rfc7595), which is defined as
```
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
```
Redox does not need the `query` and `fragment` parts. So what we need is just `scheme:param`. Then here is the proposal: [CURIE](http://www.w3.org/TR/2009/CR-curie-20090116/)
Curie's syntax is defined as
```
curie := [ [ prefix ] ':' ] reference
prefix := NCName
reference := irelative-ref (as defined in IRI)
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
```
which meets the requirement of Redox.
## Proposed implementation detail
Define two structs, `Curie` and `CurieBuf` just like `std::path::{Path, PathBuf}`.
``` rust
struct Curie<'a> {
prefix: Option<&'a str>,
reference: &'a str,
}
struct CurieBuf {
prefix: Option<String>,
reference: String,
}
```
`Curie` is immutable and it could only be created from `&str`, which would cover most use cases, such as
``` rust
let path = Curie::new("file:/home/redox/helloworld");
let no_prefix = Curie::new("mystique_content");
```
The `Curie::new` method just simply find the first `:` from the `&str` and slice it to construct the `Curie` struct, which is cheap and won't involve any unnecessary memory allocation.
The `CurieBuf` is the owned version of `Curie`.
https://gitlab.redox-os.org/redox-os/redox/-/issues/180A proposal for strongly typed resource identifier (draft)2018-06-15T11:40:04ZJeremy SollerA proposal for strongly typed resource identifier (draft)*Created by: zonyitoo*
Redox is outstanding because it introduces the concept of "Everything is an URL". But because URL is a well known word, which particularly refer to IANA URL, so would be better to use a different protocol with dif...*Created by: zonyitoo*
Redox is outstanding because it introduces the concept of "Everything is an URL". But because URL is a well known word, which particularly refer to IANA URL, so would be better to use a different protocol with different name, refer to #175 .
But CURIE is actually a String, which makes it impossible to validate in compile time. So to make use of type checking, I propose to use a strongly typed resource identifier.
## Key Points
1. Use CURIE as a stringify method of the resource identifier.
2. Resource identifier and transfer protocol is strongly typed.
3. Make good use of Rust's type system.
## Proposed Resource Identifier
**NOTE: This may be completely wrong, please just stick to the key points.**
Let's name this Resource Identifier as `Ri` (abbreviation of Resource Identifier), and it could be defined as
``` rust
trait Ri<'a>: Curie {
type Provider: Resource + CurieScheme;
type Reference: CurieReference;
type Parameter: CurieQueryString;
type Fragment: CurieFragment;
type Input: Sized;
type Output: Sized;
type Error: Sized;
fn provider(&'a self) -> &'a Self::Provider;
fn reference&'a self) -> &'a Self::Reference;
fn parameter(&'a self) -> &'a Self::Parameter;
fn fragment(&'a self) -> &'a Self::Fragment;
fn read(&mut self) -> ReaderIter<Input>;
fn write(&mut self, output: Self::Output) -> Result<(), Self::Error>;
fn from_curie<'a>(curie: &Curie<'a>) -> Self;
fn to_curie(&self) -> CurieBuf;
// Compact serialization
fn serialize(&self, w: Write) -> io::Result<()>;
fn deserialize(r: Read) -> io::Result<Self>;
}
```
### Could be converted from/to CURIE formatted string
The definition matches the definition of CURIE syntax
```
provider:reference?param1=1¶m2#fragment
```
so `Ri` could always be serialize/deserialize to/from CURIE formatted string.
Also it is a good way to provide FFI interface for other languages to call.
### Resource Protocol
All resources have a well defined **provider**, so the data transfer protocol is already defined by the **provider**. Such as the `file` provider could `read` and `write` a `[u8]`, `http` provider could `read` a `HttpRequest` and `write` a `HttpResponse`.
So the author of that resource provider will need to restrict the input and output protocol by defining `Input` and `Output` data structure.
## Note
This is just a draft propoal, implementation detail should be discussed further.
There are at least the following problems to be solved
1. Performace. Using strongly typed definition may involve performance issue, it needs to be designed properly.
2. FFI compatible. Because Redox is an OS, so the APIs will be called from various programming languages, but strongly typed APIs in Rust will become an obstacle for the other languages.
https://gitlab.redox-os.org/redox-os/website/-/issues/12RSS feeds for blog and TWiRx2018-06-17T14:52:02ZJeremy SollerRSS feeds for blog and TWiRx*Created by: NobbZ*
Please add them, they are missing!
*Created by: NobbZ*
Please add them, they are missing!
https://gitlab.redox-os.org/redox-os/redox/-/issues/191Make fail on OSX Yosemite2018-06-15T11:40:05ZJeremy SollerMake fail on OSX Yosemite*Created by: tfroseman*
Fresh clone on osx running `make all` halts with error 1
```
build/i386/../../filesystem/schemes/zfs/zfs.rs:426:21: 426:81 note: in this expansion of write! (defined in <redox macros>)
i386-elf-ld -m elf_i386 ...*Created by: tfroseman*
Fresh clone on osx running `make all` halts with error 1
```
build/i386/../../filesystem/schemes/zfs/zfs.rs:426:21: 426:81 note: in this expansion of write! (defined in <redox macros>)
i386-elf-ld -m elf_i386 -o filesystem/schemes/zfs/zfs.bin -T kernel/scheme.ld build/i386/`basename zfs/zfs`.rlib build/i386/libredox.rlib
find filesystem -not -path '*/\.*' -type f -o -type l | cut -d '/' -f2- | sort | awk '{printf("file %d,\"%s\"\n", NR, $0)}' > build/i386/filesystem.gen
nasm -f bin -o build/i386/harddrive.bin -ibuild/i386/ -ikernel/ -ifilesystem/ kernel/loader-i386.asm
kernel/loader-i386.asm:243: error: expression syntax error
kernel/loader-i386.asm:250: error: expression syntax error
kernel/loader-i386.asm:286: error: unknown preprocessor directive `%unmacro'
kernel/loader-i386.asm:286: error: label or instruction expected at start of line
kernel/loader-i386.asm:289: warning: redefining multi-line macro `file'
kernel/loader-i386.asm:298: error: unknown preprocessor directive `%unmacro'
kernel/loader-i386.asm:298: error: label or instruction expected at start of line
make: *** [build/i386/harddrive.bin] Error 1
```
https://gitlab.redox-os.org/redox-os/redox/-/issues/196Redox shell and Red2018-06-15T11:40:04ZJeremy SollerRedox shell and Red*Created by: bubnenkoff*
I think it would be good to try use as shell language Red http://www.red-lang.org/
it's much more powerful then bash, and have very low footprint
*Created by: bubnenkoff*
I think it would be good to try use as shell language Red http://www.red-lang.org/
it's much more powerful then bash, and have very low footprint
https://gitlab.redox-os.org/redox-os/redox/-/issues/199Window management: change position/size/title2018-06-15T11:40:04ZJeremy SollerWindow management: change position/size/title*Created by: nounoursheureux*
AFAIK right now `orbital` cannot change the size/position/title of a window, only its content. What would be a good way to transmit the size and position of the window along with the pixels data ?
Maybe we ...*Created by: nounoursheureux*
AFAIK right now `orbital` cannot change the size/position/title of a window, only its content. What would be a good way to transmit the size and position of the window along with the pixels data ?
Maybe we could write commands to the file:
`move x y`
`resize x y`
`set_title title`
`flush content`
But the kernel would have to parse it every time a window is updated so I don't know if this is a good solution.
What do you think ?
https://gitlab.redox-os.org/redox-os/website/-/issues/15The timestamp on TWiRx 4 is wrong2018-06-17T14:52:03ZJeremy SollerThe timestamp on TWiRx 4 is wrong*Created by: ticki*
*Created by: ticki*
https://gitlab.redox-os.org/redox-os/redox/-/issues/221Has Redox been run on bare metal yet?2018-06-15T11:40:05ZJeremy SollerHas Redox been run on bare metal yet?*Created by: RobertWHurst*
This looks like a very exciting project. I'm really impressed with the speed Redox seems to be evolving at. I'm curious, has Redox been run on bare metal yet?
*Created by: RobertWHurst*
This looks like a very exciting project. I'm really impressed with the speed Redox seems to be evolving at. I'm curious, has Redox been run on bare metal yet?
https://gitlab.redox-os.org/redox-os/redox/-/issues/227Fix clone() syscall2018-06-15T11:40:05ZJeremy SollerFix clone() syscallCurrently the clone() syscall fails because the stack is moved. If the new stack were mapped in the same location, it may work correctly.
Currently the clone() syscall fails because the stack is moved. If the new stack were mapped in the same location, it may work correctly.
https://gitlab.redox-os.org/redox-os/redox/-/issues/228Build Fails On Windows2018-06-15T11:40:05ZJeremy SollerBuild Fails On Windows*Created by: iluxonchik*
When running `windows/make.exe virtualbox` the build fails, with the following errors:
```
windows/mkdir -p build/i386
RUST_BACKTRACE=1 rustc --target=i386-unknown-redox.json -C no-prepopulate-passes -C no-vect...*Created by: iluxonchik*
When running `windows/make.exe virtualbox` the build fails, with the following errors:
```
windows/mkdir -p build/i386
RUST_BACKTRACE=1 rustc --target=i386-unknown-redox.json -C no-prepopulate-passes -C no-vectorize-loops -C no-vectorize-s
lp -C no-stack-check -C opt-level=2 -Z no-landing-pads -A dead_code -A deprecated -L build/i386 -o build/i386/libcore.rl
ib rust/libcore/lib.rs
rust/libcore\nonzero.rs:58:19: 58:25 error: expected identifier, found keyword `unsafe`
rust/libcore\nonzero.rs:58 pub const unsafe fn new(inner: T) -> NonZero<T> {
^~~~~~
rust/libcore\nonzero.rs:58:26: 58:28 error: expected `:`, found `fn`
rust/libcore\nonzero.rs:58 pub const unsafe fn new(inner: T) -> NonZero<T> {
^~
make.exe": *** [build/i386/libcore.rlib] Error 101
```
https://gitlab.redox-os.org/redox-os/redox/-/issues/230Updated intrinsics have broken the provided libcore2018-06-15T11:40:05ZJeremy SollerUpdated intrinsics have broken the provided libcore*Created by: james-darkfox*
Redox cannot be compiled with the latest nightly due to changes in the intrinsics.
`$ make qemu`
https://gist.github.com/james-darkfox/7b08cf832acf44e90da0
*Created by: james-darkfox*
Redox cannot be compiled with the latest nightly due to changes in the intrinsics.
`$ make qemu`
https://gist.github.com/james-darkfox/7b08cf832acf44e90da0