Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Linux syscall interface #63745

Open
wants to merge 8 commits into
base: master
from

Conversation

@newpavlov
Copy link
Contributor

commented Aug 20, 2019

Based on the syscall crate. Right now only x86, x86-64, arm and aarch64 architectures are supported.

This PR adds basic functions which after stabilization will allow usage of Linux syscalls on stable Rust. Syscall constants and a convenience macro imitating a variadic function can reside in third-party crates (e.g. in the aforementioned syscall). Since AFAIK only Linux guarantees stability of the syscall API, I've omitted code for FreeBSD and macOS. It was proposed to add those functions to core::os, but I think it's worth to start with a more conservative approach.

For an earlier discussion see: https://internals.rust-lang.org/t/10614

cc @kmcallister

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Aug 20, 2019

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive

This comment was marked as outdated.

Copy link
Collaborator

commented Aug 20, 2019

The job mingw-check of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-08-20T14:33:52.9389637Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-08-20T14:33:52.9613008Z ##[command]git config gc.auto 0
2019-08-20T14:33:52.9684315Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-08-20T14:33:52.9776861Z ##[command]git config --get-all http.proxy
2019-08-20T14:33:52.9891783Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/63745/merge:refs/remotes/pull/63745/merge
---
2019-08-20T14:34:28.5215015Z do so (now or later) by using -b with the checkout command again. Example:
2019-08-20T14:34:28.5215040Z 
2019-08-20T14:34:28.5215351Z   git checkout -b <new-branch-name>
2019-08-20T14:34:28.5215556Z 
2019-08-20T14:34:28.5215605Z HEAD is now at 11ff6f8c0 Merge 5e522ccfc828930a7b3f1a3c62e00ce5f30dac33 into 14890954ce17c44d944eda988c5a64bb4c5ec9eb
2019-08-20T14:34:28.5399492Z ##[section]Starting: Collect CPU-usage statistics in the background
2019-08-20T14:34:28.5402089Z ==============================================================================
2019-08-20T14:34:28.5402133Z Task         : Bash
2019-08-20T14:34:28.5402167Z Description  : Run a Bash script on macOS, Linux, or Windows
---
2019-08-20T14:40:05.8491237Z     Checking hashbrown v0.5.0
2019-08-20T14:40:06.9140118Z error: this file contains an un-closed delimiter
2019-08-20T14:40:06.9141972Z   --> src/libstd/os/linux/syscall/mod.rs:67:3
2019-08-20T14:40:06.9142253Z    |
2019-08-20T14:40:06.9142510Z 5  | #[cfg(target_arch = "x86")] {
2019-08-20T14:40:06.9143015Z    |                             - un-closed delimiter
2019-08-20T14:40:06.9143306Z ...
2019-08-20T14:40:06.9143881Z 8  | #[cfg(target_arch = "x86_64")] {
2019-08-20T14:40:06.9144157Z    |                                - un-closed delimiter
2019-08-20T14:40:06.9144358Z ...
2019-08-20T14:40:06.9144887Z 11 | #[cfg(target_arch = "aarch64")] {
2019-08-20T14:40:06.9145157Z    |                                 - un-closed delimiter
2019-08-20T14:40:06.9145546Z 67 | }
2019-08-20T14:40:06.9145743Z    |   ^
2019-08-20T14:40:06.9151733Z 
2019-08-20T14:40:06.9152371Z error: expected item after attributes
2019-08-20T14:40:06.9152371Z error: expected item after attributes
2019-08-20T14:40:06.9152784Z  --> src/libstd/os/linux/syscall/mod.rs:5:27
2019-08-20T14:40:06.9153113Z   |
2019-08-20T14:40:06.9153971Z 5 | #[cfg(target_arch = "x86")] {
2019-08-20T14:40:06.9154549Z 
2019-08-20T14:40:06.9269308Z error: aborting due to 2 previous errors
2019-08-20T14:40:06.9269395Z 
2019-08-20T14:40:06.9349721Z error: Could not compile `std`.
2019-08-20T14:40:06.9349721Z error: Could not compile `std`.
2019-08-20T14:40:06.9349822Z 
2019-08-20T14:40:06.9350106Z To learn more, run the command again with --verbose.
2019-08-20T14:40:06.9374607Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "2" "--release" "--color" "always" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json-render-diagnostics"
2019-08-20T14:40:06.9386852Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap check
2019-08-20T14:40:06.9386980Z Build completed unsuccessfully in 0:02:48
2019-08-20T14:40:06.9433269Z == clock drift check ==
2019-08-20T14:40:06.9683233Z   local time: Tue Aug 20 14:40:06 UTC 2019
2019-08-20T14:40:06.9683233Z   local time: Tue Aug 20 14:40:06 UTC 2019
2019-08-20T14:40:07.1729241Z   network time: Tue, 20 Aug 2019 14:40:07 GMT
2019-08-20T14:40:07.1729528Z == end clock drift check ==
2019-08-20T14:40:15.9750749Z ##[error]Bash exited with code '1'.
2019-08-20T14:40:15.9783883Z ##[section]Starting: Checkout
2019-08-20T14:40:15.9785491Z ==============================================================================
2019-08-20T14:40:15.9785543Z Task         : Get sources
2019-08-20T14:40:15.9785587Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

fix
@jonas-schievink

This comment has been minimized.

Copy link
Member

commented Aug 20, 2019

Are all those #[inline(always)] needed, or would #[inline] be enough? inline(always) is respected even in debug mode, which is often unnecessary.

@Centril

This comment has been minimized.

Copy link
Member

commented Aug 20, 2019

Since this is unstable it doesn't need FCP, but the use of inline assembly will need T-lang approval.

@rust-highfive

This comment was marked as outdated.

Copy link
Collaborator

commented Aug 20, 2019

The job mingw-check of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-08-20T14:53:11.1580193Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-08-20T14:53:11.1760355Z ##[command]git config gc.auto 0
2019-08-20T14:53:11.1833162Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-08-20T14:53:11.1900739Z ##[command]git config --get-all http.proxy
2019-08-20T14:53:11.2031576Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/63745/merge:refs/remotes/pull/63745/merge
---
2019-08-20T14:53:47.6991137Z do so (now or later) by using -b with the checkout command again. Example:
2019-08-20T14:53:47.6991166Z 
2019-08-20T14:53:47.6991354Z   git checkout -b <new-branch-name>
2019-08-20T14:53:47.6991380Z 
2019-08-20T14:53:47.6991442Z HEAD is now at d10a5cbe2 Merge d4cb657dd4a967d55bde2ec5edcd7ad8e2bef868 into 14890954ce17c44d944eda988c5a64bb4c5ec9eb
2019-08-20T14:53:47.7146383Z ##[section]Starting: Collect CPU-usage statistics in the background
2019-08-20T14:53:47.7149699Z ==============================================================================
2019-08-20T14:53:47.7149759Z Task         : Bash
2019-08-20T14:53:47.7149806Z Description  : Run a Bash script on macOS, Linux, or Windows
---
2019-08-20T14:59:12.9210211Z     Checking hashbrown v0.5.0
2019-08-20T14:59:13.9283103Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9283664Z   --> src/libstd/os/linux/syscall/mod.rs:15:1
2019-08-20T14:59:13.9284226Z    |
2019-08-20T14:59:13.9284483Z 14 | /// Execute syscall with 0 arguments.
2019-08-20T14:59:13.9284923Z    | ------------------------------------- previous doc comment
2019-08-20T14:59:13.9285230Z 15 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9285565Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9286254Z    |
2019-08-20T14:59:13.9286723Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9294520Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9294808Z   --> src/libstd/os/linux/syscall/mod.rs:22:1
2019-08-20T14:59:13.9294998Z    |
2019-08-20T14:59:13.9295231Z 21 | /// Execute syscall with 1 argument.
2019-08-20T14:59:13.9295231Z 21 | /// Execute syscall with 1 argument.
2019-08-20T14:59:13.9296197Z    | ------------------------------------ previous doc comment
2019-08-20T14:59:13.9296543Z 22 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9297132Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9297422Z    |
2019-08-20T14:59:13.9297852Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9309841Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9310335Z   --> src/libstd/os/linux/syscall/mod.rs:29:1
2019-08-20T14:59:13.9310783Z    |
2019-08-20T14:59:13.9311050Z 28 | /// Execute syscall with 2 arguments.
2019-08-20T14:59:13.9311050Z 28 | /// Execute syscall with 2 arguments.
2019-08-20T14:59:13.9311377Z    | ------------------------------------- previous doc comment
2019-08-20T14:59:13.9311677Z 29 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9312193Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9312400Z    |
2019-08-20T14:59:13.9313494Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9325326Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9326404Z   --> src/libstd/os/linux/syscall/mod.rs:36:1
2019-08-20T14:59:13.9326700Z    |
2019-08-20T14:59:13.9326993Z 35 | /// Execute syscall with 3 arguments.
2019-08-20T14:59:13.9326993Z 35 | /// Execute syscall with 3 arguments.
2019-08-20T14:59:13.9327342Z    | ------------------------------------- previous doc comment
2019-08-20T14:59:13.9327655Z 36 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9328020Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9328280Z    |
2019-08-20T14:59:13.9328709Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9337652Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9337966Z   --> src/libstd/os/linux/syscall/mod.rs:43:1
2019-08-20T14:59:13.9338226Z    |
2019-08-20T14:59:13.9338513Z 42 | /// Execute syscall with 4 arguments.
2019-08-20T14:59:13.9338513Z 42 | /// Execute syscall with 4 arguments.
2019-08-20T14:59:13.9338981Z    | ------------------------------------- previous doc comment
2019-08-20T14:59:13.9339285Z 43 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9339593Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9339937Z    |
2019-08-20T14:59:13.9340350Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9348798Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9349256Z   --> src/libstd/os/linux/syscall/mod.rs:52:1
2019-08-20T14:59:13.9349672Z    |
2019-08-20T14:59:13.9349914Z 51 | /// Execute syscall with 5 arguments.
2019-08-20T14:59:13.9349914Z 51 | /// Execute syscall with 5 arguments.
2019-08-20T14:59:13.9350186Z    | ------------------------------------- previous doc comment
2019-08-20T14:59:13.9350469Z 52 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9350771Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9350957Z    |
2019-08-20T14:59:13.9351322Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9357385Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T14:59:13.9357678Z   --> src/libstd/os/linux/syscall/mod.rs:61:1
2019-08-20T14:59:13.9357908Z    |
2019-08-20T14:59:13.9358225Z 60 | /// Execute syscall with 6 arguments.
2019-08-20T14:59:13.9358225Z 60 | /// Execute syscall with 6 arguments.
2019-08-20T14:59:13.9358564Z    | ------------------------------------- previous doc comment
2019-08-20T14:59:13.9359209Z 61 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T14:59:13.9359531Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T14:59:13.9359728Z    |
2019-08-20T14:59:13.9360096Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T14:59:13.9360141Z 
2019-08-20T14:59:16.3201712Z error[E0061]: this function takes 6 parameters but 7 parameters were supplied
2019-08-20T14:59:16.3202692Z   --> src/libstd/os/linux/syscall/mod.rs:66:5
2019-08-20T14:59:16.3203158Z    |
2019-08-20T14:59:16.3203590Z 66 |       platform::syscall5(n, a1, a2, a3, a4, a5, a6)
2019-08-20T14:59:16.3204449Z    | 
2019-08-20T14:59:16.3204449Z    | 
2019-08-20T14:59:16.3205230Z   ::: src/libstd/os/linux/syscall/x86_64.rs:55:1
2019-08-20T14:59:16.3206017Z    |
2019-08-20T14:59:16.3206733Z 55 | / pub unsafe fn syscall5(n: usize, a1: usize, a2: usize, a3: usize,
2019-08-20T14:59:16.3207320Z 56 | |                                 a4: usize, a5: usize) -> usize {
2019-08-20T14:59:16.3207825Z 57 | |     let ret : usize;
2019-08-20T14:59:16.3208301Z 58 | |     asm!("syscall" : "={rax}"(ret)
2019-08-20T14:59:16.3209479Z 63 | |     ret
2019-08-20T14:59:16.3209896Z 64 | | }
2019-08-20T14:59:16.3210305Z    | |_- defined here
2019-08-20T14:59:16.3210453Z 
2019-08-20T14:59:16.3210453Z 
2019-08-20T14:59:16.6785444Z error: aborting due to 8 previous errors
2019-08-20T14:59:16.6785726Z 
2019-08-20T14:59:16.6786095Z For more information about this error, try `rustc --explain E0061`.
2019-08-20T14:59:16.7137807Z error: Could not compile `std`.
2019-08-20T14:59:16.7137915Z 
2019-08-20T14:59:16.7138235Z To learn more, run the command again with --verbose.
2019-08-20T14:59:16.7172463Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "2" "--release" "--color" "always" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json-render-diagnostics"
2019-08-20T14:59:16.7179151Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap check
2019-08-20T14:59:16.7179373Z Build completed unsuccessfully in 0:02:40
2019-08-20T14:59:16.7237330Z == clock drift check ==
2019-08-20T14:59:16.7253568Z   local time: Tue Aug 20 14:59:16 UTC 2019
2019-08-20T14:59:16.7253568Z   local time: Tue Aug 20 14:59:16 UTC 2019
2019-08-20T14:59:16.8161226Z   network time: Tue, 20 Aug 2019 14:59:16 GMT
2019-08-20T14:59:16.8165050Z == end clock drift check ==
2019-08-20T14:59:23.4489510Z ##[error]Bash exited with code '1'.
2019-08-20T14:59:23.4523874Z ##[section]Starting: Checkout
2019-08-20T14:59:23.4527543Z ==============================================================================
2019-08-20T14:59:23.4527606Z Task         : Get sources
2019-08-20T14:59:23.4527673Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@newpavlov

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

@jonas-schievink
I think you always want syscalls inlined since they are extremely tiny, so why leave this decision up to compiler?

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Aug 20, 2019

The job mingw-check of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-08-20T15:19:49.9873241Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-08-20T15:19:50.0076607Z ##[command]git config gc.auto 0
2019-08-20T15:19:50.0116659Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-08-20T15:19:50.0181868Z ##[command]git config --get-all http.proxy
2019-08-20T15:19:50.0330688Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/63745/merge:refs/remotes/pull/63745/merge
---
2019-08-20T15:20:25.1346214Z do so (now or later) by using -b with the checkout command again. Example:
2019-08-20T15:20:25.1346242Z 
2019-08-20T15:20:25.1346451Z   git checkout -b <new-branch-name>
2019-08-20T15:20:25.1346479Z 
2019-08-20T15:20:25.1346523Z HEAD is now at d7dd4db7e Merge 5aa44a689b0c0bfb1790d70542fec3e98b26d44f into 51879c3abaedb926739095d19a2af638ee6a07d8
2019-08-20T15:20:25.1529356Z ##[section]Starting: Collect CPU-usage statistics in the background
2019-08-20T15:20:25.1532255Z ==============================================================================
2019-08-20T15:20:25.1532309Z Task         : Bash
2019-08-20T15:20:25.1532355Z Description  : Run a Bash script on macOS, Linux, or Windows
---
2019-08-20T15:25:57.9661785Z     Checking hashbrown v0.5.0
2019-08-20T15:25:58.9906429Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:58.9906973Z   --> src/libstd/os/linux/syscall/mod.rs:15:1
2019-08-20T15:25:58.9907213Z    |
2019-08-20T15:25:58.9907529Z 14 | /// Execute syscall with 0 arguments.
2019-08-20T15:25:58.9907892Z    | ------------------------------------- previous doc comment
2019-08-20T15:25:58.9908205Z 15 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:58.9908659Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:58.9908908Z    |
2019-08-20T15:25:58.9909538Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:58.9922893Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:58.9923255Z   --> src/libstd/os/linux/syscall/mod.rs:22:1
2019-08-20T15:25:58.9923574Z    |
2019-08-20T15:25:58.9923932Z 21 | /// Execute syscall with 1 argument.
2019-08-20T15:25:58.9923932Z 21 | /// Execute syscall with 1 argument.
2019-08-20T15:25:58.9924277Z    | ------------------------------------ previous doc comment
2019-08-20T15:25:58.9924775Z 22 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:58.9925217Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:58.9925503Z    |
2019-08-20T15:25:58.9926152Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:58.9941656Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:58.9941996Z   --> src/libstd/os/linux/syscall/mod.rs:29:1
2019-08-20T15:25:58.9942847Z    |
2019-08-20T15:25:58.9943172Z 28 | /// Execute syscall with 2 arguments.
2019-08-20T15:25:58.9943172Z 28 | /// Execute syscall with 2 arguments.
2019-08-20T15:25:58.9943479Z    | ------------------------------------- previous doc comment
2019-08-20T15:25:58.9944191Z 29 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:58.9945047Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:58.9945303Z    |
2019-08-20T15:25:58.9945805Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:58.9946165Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:58.9946488Z   --> src/libstd/os/linux/syscall/mod.rs:36:1
2019-08-20T15:25:58.9946718Z    |
2019-08-20T15:25:58.9947008Z 35 | /// Execute syscall with 3 arguments.
2019-08-20T15:25:58.9947008Z 35 | /// Execute syscall with 3 arguments.
2019-08-20T15:25:58.9947394Z    | ------------------------------------- previous doc comment
2019-08-20T15:25:58.9947718Z 36 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:58.9948294Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:58.9948537Z    |
2019-08-20T15:25:58.9948959Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:58.9959031Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:58.9959393Z   --> src/libstd/os/linux/syscall/mod.rs:43:1
2019-08-20T15:25:58.9959645Z    |
2019-08-20T15:25:58.9960092Z 42 | /// Execute syscall with 4 arguments.
2019-08-20T15:25:58.9960092Z 42 | /// Execute syscall with 4 arguments.
2019-08-20T15:25:58.9960582Z    | ------------------------------------- previous doc comment
2019-08-20T15:25:58.9990111Z 43 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:58.9990526Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:58.9990778Z    |
2019-08-20T15:25:58.9991389Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:59.0032239Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:59.0032570Z   --> src/libstd/os/linux/syscall/mod.rs:52:1
2019-08-20T15:25:59.0032804Z    |
2019-08-20T15:25:59.0033517Z 51 | /// Execute syscall with 5 arguments.
2019-08-20T15:25:59.0033517Z 51 | /// Execute syscall with 5 arguments.
2019-08-20T15:25:59.0033858Z    | ------------------------------------- previous doc comment
2019-08-20T15:25:59.0034182Z 52 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:59.0034932Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:59.0035348Z    |
2019-08-20T15:25:59.0035802Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:59.0036156Z error: an inner attribute is not permitted following an outer doc comment
2019-08-20T15:25:59.0036446Z   --> src/libstd/os/linux/syscall/mod.rs:61:1
2019-08-20T15:25:59.0036673Z    |
2019-08-20T15:25:59.0036960Z 60 | /// Execute syscall with 6 arguments.
2019-08-20T15:25:59.0036960Z 60 | /// Execute syscall with 6 arguments.
2019-08-20T15:25:59.0037306Z    | ------------------------------------- previous doc comment
2019-08-20T15:25:59.0037626Z 61 | #![unstable(feature = "linux_syscall", issue = "0")]
2019-08-20T15:25:59.0038007Z    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute
2019-08-20T15:25:59.0038410Z    |
2019-08-20T15:25:59.0038980Z    = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
2019-08-20T15:25:59.0039041Z 
2019-08-20T15:26:01.4472243Z error[E0061]: this function takes 6 parameters but 7 parameters were supplied
2019-08-20T15:26:01.4473297Z   --> src/libstd/os/linux/syscall/mod.rs:66:5
2019-08-20T15:26:01.4473848Z    |
2019-08-20T15:26:01.4475138Z 66 |       platform::syscall5(n, a1, a2, a3, a4, a5, a6)
2019-08-20T15:26:01.4476541Z    | 
2019-08-20T15:26:01.4476541Z    | 
2019-08-20T15:26:01.4477155Z   ::: src/libstd/os/linux/syscall/x86_64.rs:54:1
2019-08-20T15:26:01.4477681Z    |
2019-08-20T15:26:01.4478524Z 54 | / pub unsafe fn syscall5(n: usize, a1: usize, a2: usize, a3: usize,
2019-08-20T15:26:01.4479129Z 55 | |                                 a4: usize, a5: usize) -> usize {
2019-08-20T15:26:01.4479903Z 56 | |     let ret : usize;
2019-08-20T15:26:01.4480558Z 57 | |     asm!("syscall" : "={rax}"(ret)
2019-08-20T15:26:01.4482126Z 62 | |     ret
2019-08-20T15:26:01.4482693Z 63 | | }
2019-08-20T15:26:01.4483273Z    | |_- defined here
2019-08-20T15:26:01.4483536Z 
2019-08-20T15:26:01.4483536Z 
2019-08-20T15:26:01.7932348Z error: aborting due to 8 previous errors
2019-08-20T15:26:01.7932610Z 
2019-08-20T15:26:01.7933103Z For more information about this error, try `rustc --explain E0061`.
2019-08-20T15:26:01.8301099Z error: Could not compile `std`.
2019-08-20T15:26:01.8301207Z 
2019-08-20T15:26:01.8301482Z To learn more, run the command again with --verbose.
2019-08-20T15:26:01.8333695Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "2" "--release" "--color" "always" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json-render-diagnostics"
2019-08-20T15:26:01.8347038Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap check
2019-08-20T15:26:01.8347127Z Build completed unsuccessfully in 0:02:45
2019-08-20T15:26:01.8400698Z == clock drift check ==
2019-08-20T15:26:01.8825655Z   local time: Tue Aug 20 15:26:01 UTC 2019
2019-08-20T15:26:01.8825655Z   local time: Tue Aug 20 15:26:01 UTC 2019
2019-08-20T15:26:02.0871058Z   network time: Tue, 20 Aug 2019 15:26:02 GMT
2019-08-20T15:26:02.0872024Z == end clock drift check ==
2019-08-20T15:26:09.1046132Z ##[error]Bash exited with code '1'.
2019-08-20T15:26:09.1107950Z ##[section]Starting: Checkout
2019-08-20T15:26:09.1109871Z ==============================================================================
2019-08-20T15:26:09.1109938Z Task         : Get sources
2019-08-20T15:26:09.1109984Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@newpavlov

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

Should I create a tracking issue now or wait for T-lang approval?

@Centril

This comment has been minimized.

Copy link
Member

commented Aug 20, 2019

Now would be preferable. The language team will need to approve stabilization itself later.

@newpavlov newpavlov referenced this pull request Aug 20, 2019
0 of 2 tasks complete
typo fix
Co-Authored-By: Peter Atashian <retep998@gmail.com>
let ret : usize;

//
// this fails when building without optimizations:

This comment has been minimized.

Copy link
@joshtriplett

joshtriplett Aug 20, 2019

Member

Would something like the optimize attribute work here?

This comment has been minimized.

Copy link
@newpavlov

newpavlov Aug 20, 2019

Author Contributor

It could, but since optimize attribute is ignored in the presence of -C opt-level=n, I am not sure if we should use it. Although it's worth to check if this bug is still present.

This comment has been minimized.

Copy link
@joshtriplett

joshtriplett Sep 8, 2019

Member

@newpavlov I'm really surprised that optimize is ignored based on command-line options; this is a good use case for it always working.

I'd love to avoid this extra overhead if possible, but this doesn't need to be a blocker.

This comment has been minimized.

Copy link
@Centril

Centril Sep 8, 2019

Member

I would be concerned if optimize(...) would impact whether the build is successful / not. optimize(...) is a hint and has zero guarantees.

#[inline(always)]
pub unsafe fn syscall0(n: usize) -> usize {
let ret : usize;
asm!("int $$0x80" : "={eax}"(ret)

This comment has been minimized.

Copy link
@bdonlan

bdonlan Aug 23, 2019

Should these be calling via the VDSO instead?

@joshtriplett

This comment has been minimized.

Copy link
Member

commented Aug 24, 2019

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Aug 29, 2019

The job mingw-check of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-08-29T10:45:13.5274711Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-08-29T10:45:13.5462575Z ##[command]git config gc.auto 0
2019-08-29T10:45:13.5543678Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-08-29T10:45:13.5602429Z ##[command]git config --get-all http.proxy
2019-08-29T10:45:13.5745804Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/63745/merge:refs/remotes/pull/63745/merge
---
2019-08-29T10:51:16.3680616Z     Checking hashbrown v0.5.0
2019-08-29T10:51:18.0645483Z error[E0544]: multiple stability levels
2019-08-29T10:51:18.0646545Z  --> src/libstd/os/linux/syscall/mod.rs:2:1
2019-08-29T10:51:18.0646935Z   |
2019-08-29T10:51:18.0647366Z 2 | #![unstable(feature = "linux_syscall", issue = "63748")]
2019-08-29T10:51:18.0647972Z 
2019-08-29T10:51:19.8038560Z error: aborting due to previous error
2019-08-29T10:51:19.8039257Z 
2019-08-29T10:51:19.8374687Z error: Could not compile `std`.
---
2019-08-29T10:51:19.8452489Z == clock drift check ==
2019-08-29T10:51:19.8477600Z   local time: Thu Aug 29 10:51:19 UTC 2019
2019-08-29T10:51:19.9307915Z   network time: Thu, 29 Aug 2019 10:51:19 GMT
2019-08-29T10:51:19.9311940Z == end clock drift check ==
2019-08-29T10:51:24.2782997Z ##[error]Bash exited with code '1'.
2019-08-29T10:51:24.2810690Z ##[section]Starting: Checkout
2019-08-29T10:51:24.2812318Z ==============================================================================
2019-08-29T10:51:24.2812373Z Task         : Get sources
2019-08-29T10:51:24.2812438Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@newpavlov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 8, 2019

@gnzlbg
Well, you simply let a third-part compiler to handle assembly, which is not a great long-term solution in my opinion.

@gnzlbg

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2019

Sure, my point here was only that if the main goal here is to be able to use these on stable Rust, then that's already possible.

There are merged RFCs (e.g. global_asm!) that could be used to avoid the need of using a build.rs at all, such that exposing these here wouldn't be necessary if we were to stabilize those.

You mentioned on internals that part of the motivation is (1) experimentation, but for that one can use nightly or stable already, and (2) a libc-free standard library, but for that, we don't need to expose these APIs from libstd at all, they can be private details of libstd.


@Centril

Since this is unstable it doesn't need FCP, but the use of inline assembly will need T-lang approval.

Why doesn't this require T-Libs approval? Feels like the library team should at least sign on the overall direction of exposing raw OS kernel APIs from libstd. Are we already exposing any?

We currently expose some C lib APIs (e.g. raw thread handles, file handles, etc.), but we have messed that up on some platforms before, and the result there has been that you can't properly interface the raw items of libstd with, e.g., the actual APIs provided in the libc crate and actually fixing this would be a breaking change.

For example, the API provided here using usize cannot directly interface with the system call constants of the libc crate, which are of type libc::c_long (i32 or i64 != usize), which means that users calling these need to either re-implement all constants (e.g. in the syscall crate), or use as _ casts everywhere. Not a big deal, but unnecessary friction IMO.

Then there is also the issue that it probably makes sense to actually get rid of all kernel APIs from libc and move them to a third party linux crate, that knows things like the Linux kernel version being targeted. It would IMO make more sense to enable building those crates properly on crates.io where breaking changes can happen by just bumping the crate version instead of exposing these from libstd where things are in stone forever and we can't fix them.

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 8, 2019

Why doesn't this require T-Libs approval? Feels like the library team should at least sign on the overall direction of exposing raw OS kernel APIs from libstd. Are we already exposing any?

Something requiring language team approval does not imply that it does not also require libs team approval.

@alexcrichton alexcrichton removed the T-lang label Sep 9, 2019

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Sep 9, 2019

I'm removing the T-lang label here and requesting that purely from a libs perspective that we close this for now:

@rfcbot fcp close

I'm not certain that this pulls its weight in the standard library to be added as a module. I think that this code could live on crates.io and be maintained there. It looks like the only benefit of moving it into libstd is that it gets to use asm! or global_asm!, but that alone I do not believe justifies its existince in the standard library.

I would personally propose that we close this as a feature that the libs team would not want to add to libstd, and in the meantime a stable version on crates.io would need to use an assembler to compile out-of-line assembly, check in precompiled object files, or push on stabilization of asm! or global_asm!.

@rfcbot

This comment has been minimized.

Copy link

commented Sep 9, 2019

Team member @alexcrichton has proposed to close this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@joshtriplett

This comment has been minimized.

Copy link
Member

commented Sep 9, 2019

As a data point: C libraries like glibc provide functions like syscall, and it seems useful for us to do the same.

To look at this a slightly different way: if asm! were stable today, I'd still suggest that there's value in having syscall functions in the standard library.

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

The purpose of the FCP isn't really to say whether this is a good feature or not, it's purely about it's inclusion in the standard library. To that end Rust has its own style and preference for what goes into the standard library, and while we take inspiration from other languages we don't necessarily copy ideas even if they were successful. For example Rust's standard library is way smaller than Python's, it's also far more portable than C's. I agree it's useful to have Linux syscall utilities in a Rust library but I personally believe it's not fitting in the style of the Rust standard library to have it there when a crates.io crate would suffice.

@newpavlov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 10, 2019

@alexcrichton

I personally believe it's not fitting in the style of the Rust standard library to have it there when a crates.io crate would suffice.

You can say absolutely the same about all OS-dependent functionality. IIUC std::fs and std::net can live in a crates.io crate without issues as well, they are even more suitable for that than syscalls since they do not have to rely on nightly-only features for a pure-Rust solution (ofc in a sense that we are allowed to use libc/winapi/etc.). Portability argument is also weak in my opinion, we already have non-portable OS-specific functionality and adding syscalls will not change much in this regard.

Syscalls is the most fundamental way of talking to a Linux system, and all other functionality for Linux targets is built on top of it (granted, right now we offload all of the work to libc, but it may change). So I believe having syscalls in std is a very fitting for a systems programming language. Plus third-party crates may become unmaintained (as has happened with the syscall crate), so having it in std will allow authors to depend on raw syscalls more confidently.

@withoutboats

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

A few separate comments on the discussion so far:

  • I'm not convinced the problems with the libc interface are enough to justify adding this to std when the libc interface is available on stable using just the libc crate. I realize there's a connection to a libc-free std, but this proposal alone doesn't get us much closer to that because std will still depend on libc just as much as it does today.

  • I think it's really unclear how we will ever move forward with adding any significant additional OS-specific functionality to std. This is connected to a larger sense of stagnancy within std, where I'm unclear if the way we've done things historically has worked out well or not, and it feels like there's very little inertia behind solving the various organizational problems with how std currently handles portability issues.

  • I do not believe this should ever have been tagged T-lang. I find the pattern of overreach in what gets tagged T-lang rather exhausting.

@newpavlov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 10, 2019

I realize there's a connection to a libc-free std, but this proposal alone doesn't get us much closer to that because std will still depend on libc just as much as it does today.

I like to think about it as a first (small) step in this direction. Also note that there is a proposal to incrementally port std to syscalls where we don't need libc for interoperability with C/C++. (Fully libc-free std will need a separate target as was proposed by @japaric in the linked RFC issue)

Plus it's not only about libc-free std, but also about writing libraries and applications which use syscalls directly instead of linking to shared libraries (e.g. liburing), which may not be present on a user system. Yes, we can go via libc's syscall or use cc to link externals .S files, but it looks like a needless indirection to me.

@withoutboats

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

I understand, but right now we haven't made any commitment to follow that plan through. If we had decided it was an important goal for the project to have a libc-free std, I'd be much more in favor of this API addition.

@joshtriplett

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

@gnzlbg

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@joshtriplett

if asm! were stable today, I'd still suggest that there's value in having syscall functions in the standard library.

What would that value be?

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

I am by no means the only voice of the library team, I'm just writing down my own personal opinions. Others may feel quite differently!

I agree with others that the idea of a libc-less target should not at all be anywhere near the motivation for this PR, such a target existing and whether or not we include the syscalls in libstd is both orthogonal in terms of API design and also orthogonal in terms of technical implementation. This proposal must be worthy in its own right regardless of whether a libc-less target is considered.

@ojeda

This comment has been minimized.

Copy link

commented Sep 12, 2019

In a way, these functions constitute the "FFI to the kernel", because they allow to call and pass data to it. And that fits pretty well in std::ffi's description: "This module provides utilities to handle data across non-Rust interfaces, like (...) the underlying operating system".

For example Rust's standard library (...) it's also far more portable than C's.

What do you mean? C's standard library is probably the most widely ported library.

@retep998

This comment has been minimized.

Copy link
Member

commented Sep 13, 2019

What do you mean? C's standard library is probably the most widely ported library.

Code using the C standard library is not that portable though. The C standard library on Windows is a trash fire where getting unicode support in filesystem paths requires using non-portable wide versions of everything, and there's so many platform and compiler specific extensions to the C standard library that many software relies on. The Rust standard library is much more consistent and sane across the set of platforms it supports than the C standard library.

@ojeda

This comment has been minimized.

Copy link

commented Sep 13, 2019

Code using the C standard library is not that portable though. The C standard library on Windows is a trash fire where getting unicode support in filesystem paths requires using non-portable wide versions of everything

That's on a given implementation and their decisions, not on C. It does not make the code non-portable either. For instance, you may be fine using fopen if you know before-hand the set of filenames to be open. Similarly, some platforms do not even have files, but we do not call all C code non-portable just because of them.

there's so many platform and compiler specific extensions to the C standard library that many software relies on.

Those extensions are not the C standard library. If software relies on them, that's a dependency. The same way we would have a dependency if we had to use the syscall crate here. We could also make unworldly claims like "Rust's standard library is fundamentally non-portable given std::os", but I think we agree that wouldn't be useful either.

This is why I think syscall being in std does not really subtract from Rust's portability (and, in fact, makes std more complete, considering std::os/std::ffi are already there).

The Rust standard library is much more consistent and sane across the set of platforms it supports than the C standard library.

Now that is true. The C spec is dated and, if it were to be written nowadays, it would probably be way better (e.g. w.r.t. enforcing Unicode support). However, we should note that the set of C platforms is way bigger: it is way easier to be consistent and sane across every single platform if you have less platforms to begin with (you are perfectly so if your set's size is 1 ;-), so let's give credit where credit is due.

@gnzlbg

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

It was claimed that these APIs add value even if we were to stabilize asm! and that comment has 6 thumbs up as of today, so I take that as a hint that a lot of users agree with that and I'm missing something.

I can't imagine What would that value be? because if we were to stabilize asm!, cargo add syscalls would make these APIs available to all Rust code without any downsides AFAICT.

From the amount of discussion it is at least clear to me that this is RFC material. I don't really expect an RFC for this to be able to answer that question (*), but I'm still intrigued about what am I missing.

(*) I think saying that this adds no value if asm! were to be stabilized would be ok because asm! is not stable today, and it is unclear when that would be. global_asm! looks better though, and using the cc crate works on stable Rust today, at the inconvenience of requiring a C compiler, but if you are using Linux syscalls, such a compiler is always available AFAICT.

@newpavlov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 13, 2019

@gnzlbg
As I've stated here, syscalls is the most fundamental way of talking to Linux. Considering that we already expose a fair amount of OS-dependent higher-level functionality in std, I don't see why syscalls should not be exposed as well. And it's a really low-level piece of code which easy to implement wrong. This is why having it in std is important in my opinion from user confidence PoV (as I've noted earlier syscalls crate is not maintained anymore). And I don't think it will be a big maintenance burden, since after syscalls API is "done", it's highly unlikely to require any changes in future (well, apart from introducing changes to the asm! macro). global_asm! and cc are workarounds, not proper solutions in my opinion, e.g. you want syscalls to be inlined if possible (LTO may help here, but I am not sure).

I don't see the point of writing an RFC after seeing the feedback from the team members. What will be changed by doing it? It will be just a waste of time to write an RFC which will be closed shortly afterwards...

I guess there is an idea of introducing a separate no_std crate for syscalls which will be distributed together with Rust releases (like test, alloc, etc.). It would allow to side-step the issue of adding syscalls to core and it will allow us to use asm! for syscalls. But it will be even a bigger change, than the one proposed in this PR, so I doubt it will be accepted.

@bjorn3

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

A disadventage of introducing this api, is that it makes asm support more important for a codegen backend. For cg_clif I currently already had to patch away a few inline asm sections. In most of these cases, I could just make them panic, as they should only be called when certain target features are enabled. Disabling those would just fix it. For syscalls, that would obviously not work.

@gnzlbg

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

@newpavlov

I don't see the point of writing an RFC after seeing the feedback from the team members. What will be changed by doing it? It will be just a waste of time to write an RFC which will be closed shortly afterwards...

There is a real problem here that is affecting a couple of users and for which the current workarounds aren't great. I think that a good solution for solving this problem has high chances of going successfully through the RFC process.

The feedback of the team members isn't about such an RFC, but about this PR in particular, which proposes a particular solution to that problem. This might very well be the best solution to the problem that there is, but from the information provided, nobody can really tell.

@ojeda

This comment has been minimized.

Copy link

commented Sep 13, 2019

If using asm! is an issue, we could always link an assembly file. The key is whether std should provide (or not) the functions.

@bill-myers

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

It seems a good idea to add this to libstd, since in addition to making it available to users on stable, it can then be used to incrementally change libstd code to directly make Linux syscalls instead of calling libc, which is slightly faster and could eventually allow to remove the libc dependency completely, at least for some programs, allowing to have smaller statically linked Rust binaries.

Regarding the objection of making it private, the Linux syscall interface is immutable and this is the canonical way of exposing it, so once the code is in libstd we might as well expose it.

@Ixrec

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2019

To try and proactively prevent any splitting of this discussion: the bulk of the activity was shifted back to the internals thread with this post yesterday.

@rfcbot

This comment has been minimized.

Copy link

commented Sep 18, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.