syscall issueshttps://gitlab.redox-os.org/redox-os/syscall/-/issues2024-03-16T06:46:15Zhttps://gitlab.redox-os.org/redox-os/syscall/-/issues/35Has non-latest major version of bitflags crate as dependency2024-03-16T06:46:15ZShahar OrHas non-latest major version of bitflags crate as dependencyI'd like to ask that it be updated. That's all. Thank you.I'd like to ask that it be updated. That's all. Thank you.https://gitlab.redox-os.org/redox-os/syscall/-/issues/34Update `bitflags` to v22023-12-07T15:29:58ZdaxpeddaUpdate `bitflags` to v2As in the title.
See https://github.com/bitflags/bitflags/releases/tag/2.0.0.
This is a breaking change as it modifies the exposed API.As in the title.
See https://github.com/bitflags/bitflags/releases/tag/2.0.0.
This is a breaking change as it modifies the exposed API.https://gitlab.redox-os.org/redox-os/syscall/-/issues/33Strict pointer provenance2023-06-27T08:50:59ZniluxvStrict pointer provenanceMuch of the current API violates [strict provenance](https://github.com/rust-lang/rust/issues/95228), for example `syscall::call::fmap` returning a `usize` instead of a pointer. Changing this would obviously be a breaking change, but goo...Much of the current API violates [strict provenance](https://github.com/rust-lang/rust/issues/95228), for example `syscall::call::fmap` returning a `usize` instead of a pointer. Changing this would obviously be a breaking change, but good to keep in mind for the next semver-breaking version bump (i.e. `0.4.0`).https://gitlab.redox-os.org/redox-os/syscall/-/issues/32Use a safe transmute crate2023-06-08T10:08:00ZJacob Lorentzon4ldo2@protonmail.comUse a safe transmute crateCurrently, many of the redox_syscall structs are repr(C) although using Deref impls to be convertible to regular slices. This has a few downsides, such as requiring explicit unsafe when casting *slices* of structs, as well as unsafe boil...Currently, many of the redox_syscall structs are repr(C) although using Deref impls to be convertible to regular slices. This has a few downsides, such as requiring explicit unsafe when casting *slices* of structs, as well as unsafe boilerplate. Reading padding bytes from a struct is UB, and `Stat` (on x86_64 at least) does contain implicit padding, making its Deref impl unsound (cf. https://gitlab.redox-os.org/redox-os/syscall/-/issues/29).
Some Redox drivers use `plain`, which would be a great improvement, although requiring manual `unsafe impl Plain for Struct`, and only allowing `slice_from_bytes` (as opposed to `slice_to_bytes`, which is impossible since plain does not forbid padding bytes). A better alternative might be `bytemuck`, which uses a derive-macro to safely implement traits, with the addition of being able to safely convert contiguous enums to/from ints (zerocopy would also work, but might not be ideal due to licensing).https://gitlab.redox-os.org/redox-os/syscall/-/issues/31support Rust nightly 1.54.02021-06-16T08:08:26Zpoly000support Rust nightly 1.54.0https://github.com/rust-lang/rust/pull/84310
```
error[E0557]: feature has been removed
--> /home/poly/.cargo/registry/src/github.com-1ecc6299db9ec823/redox_syscall-0.2.8/src/lib.rs:3:12
|
3 | #![feature(const_fn)] // see https://git...https://github.com/rust-lang/rust/pull/84310
```
error[E0557]: feature has been removed
--> /home/poly/.cargo/registry/src/github.com-1ecc6299db9ec823/redox_syscall-0.2.8/src/lib.rs:3:12
|
3 | #![feature(const_fn)] // see https://github.com/rust-lang/rfcs/pull/2632
| ^^^^^^^^ feature has been removed
|
= note: split into finer-grained feature gates
```https://gitlab.redox-os.org/redox-os/syscall/-/issues/30New asm!() syntax?2021-03-31T09:12:49Zcoolreader18New asm!() syntax?On the current nightly, building redox_syscall fails due to RFC 2873 renaming the `asm!()` macro to `llvm_asm!()` and moving it to be replaced by a new inline assembly syntax. Here's an example of the error message (I get about 6 of thes...On the current nightly, building redox_syscall fails due to RFC 2873 renaming the `asm!()` macro to `llvm_asm!()` and moving it to be replaced by a new inline assembly syntax. Here's an example of the error message (I get about 6 of these total):
```
error: the legacy LLVM-style asm! syntax is no longer supported
--> /home/coolreader18/.cargo/registry/src/github.com-1ecc6299db9ec823/redox_syscall-0.1.56/src/io/pio.rs:31:13
|
31 | asm!("in $0, $1" : "={al}"(value) : "{dx}"(self.port) : "memory" : "intel", "volatile");
| ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: replace with: `llvm_asm!`
|
= note: consider migrating to the new asm! syntax specified in RFC 2873
= note: alternatively, switch to llvm_asm! to keep your code working as it is
```
What would be the best course of action? I understand that redox stays on somewhat up-to-date version of nightly, so would it be ok to update the rust-toolchain in the redox repo and just use either the new asm syntax or the new llvm_asm feature gate? Or maybe have a build.rs check whether the nightly version calls the llvm asm macro llvm_asm!() or asm!() and do conditional compilation off of that?https://gitlab.redox-os.org/redox-os/syscall/-/issues/29Unsound APIs2023-12-06T09:50:50ZDawid CiężarkiewiczUnsound APIsHi,
I'm looking at the crev review of `redox_syscall`: https://github.com/MaulingMonkey/crev-proofs/commit/0e29470384492587074e19a2a1ff7adc341bea25 , pasted inline:
```
version: -1
date: "2019-07-24T14:53:11.836480900-07:00"
from:
id...Hi,
I'm looking at the crev review of `redox_syscall`: https://github.com/MaulingMonkey/crev-proofs/commit/0e29470384492587074e19a2a1ff7adc341bea25 , pasted inline:
```
version: -1
date: "2019-07-24T14:53:11.836480900-07:00"
from:
id-type: crev
id: 6OZqHXqyUAF57grEY7IVMjRljdd9dgDxiNtr1NF1BdY
url: "https://github.com/MaulingMonkey/crev-proofs"
package:
source: "https://crates.io"
name: redox_syscall
version: 0.1.56
revision: e3fd644ba9830d104c309f77c36dc6b94f92f2b1
digest: FTw1q2J_JAvJHFyP4Xn0URVlkBDh1xI3mxs5sFn_A-U
review:
thoroughness: low
understanding: low
rating: negative
comment: |
Exposes unsound APIs, lots of unverified syscalls.
Reviewed:
src\arch\*.rs: Skimmed... looks reasonable, but didn't verify correct instructions / register invalidation.
src\io\dma.rs: Some unsafe... looks correct, but not thoroughly tested.
src\io\io.rs: +1
src\io\mmio.rs: UNSOUND (can construct uninitialized() T via "safe" `Mmio::new()`!)
src\io\mod.rs: +1
src\io\pio.rs: Some unsafe... looks reasonable, but didn't verify correct instructions.
src\scheme\generate.sh: +1
src\scheme\mod.rs: +1
src\scheme\scheme*.rs: UNSOUND (can construct arbitrary slices from arbitrary Packet s via `Scheme*::handle`)
.cargo_vcs_info.json: +1
.cargo-ok: +1
.gitlab-ci.yml: +1
Cargo.toml: +1
Cargo.toml.orig: +1
LICENSE: +1
README.md: +1
Skimmed:
src\call.rs: Lots of unsafe syscalls... unverified.
src\data.rs: UNSOUND (Map deref etc.)
src\error.rs: No tests for STR_ERROR, but at least it's sound.
src\flag.rs: Sound, magic constant city, meh.
src\lib.rs: LEAKS UNSOUND TRAITS into public interface!
src\number.rs: Safe, magic constant city.
src\tests.rs: Unsafe, but only #[test]s
```
I just wanted to bring it to your attention. I guess in a low-level crate like this it might be more complicated to judge the `unsafe` issues. Please let me know what you think. Are some of the unsafety issues real? Is there anything that can be improved about it?https://gitlab.redox-os.org/redox-os/syscall/-/issues/28WASM WASI compatibility2023-10-15T09:06:40ZDaniel OlanoWASM WASI compatibilityHello! Just wanted to bring some discussion about this topic.
There is this big fancy train call WASM that will surely get far and seems to me that people jumping on board might benefit form its momentum. And what better that a new fre...Hello! Just wanted to bring some discussion about this topic.
There is this big fancy train call WASM that will surely get far and seems to me that people jumping on board might benefit form its momentum. And what better that a new fresh, secure and lightweight OS? It might be already to late to make Redox completely Web Assembly centric but some adaptations could be made to make it play better with wasm apps using the Web Assembly System Interface? The plan of WASI is to have a modular set of non web system APIs so WASM apps can run outside of the web in a secure way, currently they started with the [core API system calls](https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md) to implement basic IO functionality.
I don't know much about anything but in my simple way to see things I would seem that if Redox syscalls heppen to be the same as WASI and a WASM app targeting this kind of runtime is run using a JIT compiler built-in or compiled ahead of time at "installation" time, the app just "just work"? What do you guys think about being more web assembly friendly? does it deviate too much from the design choices of Redox? ultimately I just want to see this project to succeed, been a patreon for some time and see an opportunity there to gain back momentum that has been lost over time. :sweat\_smile:
As web technologies supporter I would definitely be very exited to see a WASM centric OS whether is Redox based or not, WASI runtimes will be popular and Operating systems built around it will be used, for sure there will be linux distros just for that that will see a big success in the cloud for example but I rather see Redox there ;) on the plus side all this wasm stuff compilers and runtimes are being written in Rust so they would integrate much nicely with Redox than with any other OS.
What do you think? makes some sense?https://gitlab.redox-os.org/redox-os/syscall/-/issues/27What is the purpose of `buf` in arguments of `dup`?2018-06-15T05:04:53ZJeremy SollerWhat is the purpose of `buf` in arguments of `dup`?*Created by: equal-l2*
`dup` has `buf: &[u8]` as an argument.
What is the purpose of this argument?
I saw it was used in [termion in the implementation of `isatty`](https://github.com/ticki/termion/blob/master/src/sys/redox/tty.rs#L8).*Created by: equal-l2*
`dup` has `buf: &[u8]` as an argument.
What is the purpose of this argument?
I saw it was used in [termion in the implementation of `isatty`](https://github.com/ticki/termion/blob/master/src/sys/redox/tty.rs#L8).https://gitlab.redox-os.org/redox-os/syscall/-/issues/26fchmod API2021-08-06T13:19:17ZSamwiseFilmoremggmugginsmc@gmail.comfchmod API`fchmod` takes two `u32`'s as uid and gid which are subsequently cast to usize. Everywhere else in the API uids and gids are `usize`. I'd prefer to just use `u32` for uid and gid, but that's a personal preference and since `usize` is use...`fchmod` takes two `u32`'s as uid and gid which are subsequently cast to usize. Everywhere else in the API uids and gids are `usize`. I'd prefer to just use `u32` for uid and gid, but that's a personal preference and since `usize` is used everywhere else, I don't mind too much, but I'd like to see `fchmod` get changed to reflect the decision on type for uid and gid, regardless.
Originally posted in #21 https://gitlab.redox-os.org/redox-os/syscall/-/issues/24Perhaps building syscall on non-Redox platforms should error2018-06-13T19:39:49ZIan Douglas ScottPerhaps building syscall on non-Redox platforms should errorOtherwise it is potentially possible to build a program using the library on other platforms, but it will not work correctly, and potentially cause undefined behaviour. The best way to do this is probably with a `build.rs` test.
I am ...Otherwise it is potentially possible to build a program using the library on other platforms, but it will not work correctly, and potentially cause undefined behaviour. The best way to do this is probably with a `build.rs` test.
I am somewhat concerned, though, that some software ported to Redox is probably depending unconditionally on the syscall crate, and this change would make it fail to build on other platforms. This is probably the right thing to do though, and those crates can be fixed (I guess we can test every crate on crates.io that depends on redox_syscall?).https://gitlab.redox-os.org/redox-os/syscall/-/issues/21Improve syscall interfaces2023-10-23T15:42:38ZJeremy SollerImprove syscall interfaces
The current ABI stability policy, is to define the stable ABI layer in relibc, and allow internal breaking changes to the syscall ABI. This may and likely will change in the future, when the kernel and its interfaces reach a certain le...
The current ABI stability policy, is to define the stable ABI layer in relibc, and allow internal breaking changes to the syscall ABI. This may and likely will change in the future, when the kernel and its interfaces reach a certain level of maturity.
## Move most file operations to the fd
- [x] ~~Change `chmod(path, mode)` to `fchmod(fd, mode)`~~ => `chmod` has been removed in favor of `fchmod`
- [x] ~~Add `fchown(fd, owner, group)`~~ => already added
## Make `dup` less magical
- [ ] Change `dup(fd, buf)` to `dup(fd)`
- [ ] Change `dup2(fd, newfd, buf)` to `dup2(fd, newfd)`
- [ ] Add `openat(fd, path, flags)`.
With the dup buffer removed, schemes will no longer receive SYS_DUP requests, instead SYS_OPENAT.
## Use standard methods more often
### memory management
- [x] ~~Use `fmap` to implement `physmap`~~
- [x] ~~Use `funmap` to implement `physunmap`~~
- [ ] Replace `physalloc`
- [ ] Replace `physfree`
- [ ] Decide whether `virttophys` should still exist. One of the proposed alternatives to physalloc/physfree is to do mmap with a "physically contiguous" flag, which would necessitate a syscall for virt=>phys translation.
- [x] ~~Consider using `fmap` to implement `brk`~~ => SYS_BRK has already been removed from the kernel
### process management
(let `proc/...` be an alias for `thisproc:current/...`)
- [x] ~~Replace chdir and getcwd with `proc/cwd`~~
- Replace getegid, getens, geteuid, getns, getpid, getpgid/setpgid, getppid, getuid, setregid, setrens, setreuid, umask, sigprocmask with corresponding files
- Replace sigaction get/set with `proc/sigaction`
# Cleanup other syscalls
- [x] Replace `pipe2` with ~~open/openat~~ open/dup
- Implement or remove `link(old, new)`
# Misc
- Remove `int 0x80` on x86_64?
- Add UTIME_NOW and UTIME_OMIT?
# ~~ABI stabilization (WIP)~~
~~A large part of growing the adoption of a kernel is to stabilize the ABI used. I would like to work on a stable ABI in the next few months, and a 1.0 version of the `kernel` and `syscall` crate. I am proposing the following for ABI stabilization:~~Jeremy SollerJeremy Sollerhttps://gitlab.redox-os.org/redox-os/syscall/-/issues/5Do not compile if the platform is not redox2018-06-14T03:00:11ZJeremy SollerDo not compile if the platform is not redox*Created by: P-E-Meunier*
So, I wrote an alternative build system for Rust, based on Nix, to reduce compilation times when deploying using NixOps.
See https://nest.pijul.com/pmeunier/nix-rust
It works fine, except for one thing: the...*Created by: P-E-Meunier*
So, I wrote an alternative build system for Rust, based on Nix, to reduce compilation times when deploying using NixOps.
See https://nest.pijul.com/pmeunier/nix-rust
It works fine, except for one thing: the `time` crate depends on `redox-syscall` only on when the platform is Redox. Unfortunately, that information is not written to `Cargo.lock` (for a good reason: portability of `Cargo.lock`).
So, I'd love it if this entire crate could compile on all platforms, but just compile nothing on non-Redox platforms.https://gitlab.redox-os.org/redox-os/syscall/-/issues/17Nanosleep should allow None/null rmtp2018-06-13T19:39:50ZIan Douglas ScottNanosleep should allow None/null rmtpThe kernel handles this, but `syscall` doesn't. I guess the only way is a breaking change, making it an `Option`?The kernel handles this, but `syscall` doesn't. I guess the only way is a breaking change, making it an `Option`?https://gitlab.redox-os.org/redox-os/syscall/-/issues/15Rename library to redox_syscall2018-06-13T19:39:50ZJeremy SollerRename library to redox_syscallThis would probably be a major version bump, but it would be consistent with the crate nameThis would probably be a major version bump, but it would be consistent with the crate namehttps://gitlab.redox-os.org/redox-os/syscall/-/issues/7Should `Stat` et al be repr(C)?2018-06-15T05:04:53ZIan Douglas ScottShould `Stat` et al be repr(C)?As far as I am aware, the current layout of this stuct and the others is undefined, which makes it impossible to reliably use from C. With Rust code in libc, it could be copied to a C struct, but that would be inefficient.
It is `repr...As far as I am aware, the current layout of this stuct and the others is undefined, which makes it impossible to reliably use from C. With Rust code in libc, it could be copied to a C struct, but that would be inefficient.
It is `repr(packed)`, but I think that still allows Rust to reorder the elements. I don't know if this is currently an issue, but it is in principle undefined behavior. (And it could theoretically change in a future Rust version too, breaking the kernel ABI, though we may not care about that.)