Expose Linux syscall interface #63745
Conversation
|
r? @kennytm (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
|
Are all those |
Centril
added
T-lang
|
Since this is unstable it doesn't need FCP, but the use of inline assembly will need T-lang approval. |
This comment has been minimized.
This comment has been minimized.
|
@jonas-schievink |
|
The job Click to expand the log.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 |
|
Should I create a tracking issue now or wait for T-lang approval? |
|
Now would be preferable. The language team will need to approve stabilization itself later. |
| let ret : usize; | ||
|
|
||
| // | ||
| // this fails when building without optimizations: |
There was a problem hiding this comment.
Would something like the optimize attribute work here?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
Should these be calling via the VDSO instead?
|
On August 23, 2019 11:46:33 AM PDT, bdonlan ***@***.***> wrote:
bdonlan commented on this pull request.
> @@ -0,0 +1,115 @@
+#[inline(always)]
+pub unsafe fn syscall0(n: usize) -> usize {
+ let ret : usize;
+ asm!("int $$0x80" : "={eax}"(ret)
Should these be calling via the VDSO instead?
Ideally yes, but doing so would require 1) accessing the auxiliary vector and 2) parsing ELF.
|
|
The job Click to expand the log.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 |
rfcbot
added
proposed-final-comment-period
|
As a data point: C libraries like glibc provide functions like To look at this a slightly different way: if |
|
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. |
You can say absolutely the same about all OS-dependent functionality. IIUC 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 |
|
A few separate comments on the discussion so far:
|
I like to think about it as a first (small) step in this direction. Also note that there is a proposal to incrementally port Plus it's not only about |
|
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. |
|
On Tue, Sep 10, 2019 at 09:13:27AM -0700, Artyom Pavlov wrote:
>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](https://internals.rust-lang.org/t/crazy-idea-incrementally-porting-linux-std-to-syscalls/10404) 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)
Strictly speaking, porting std itself to work without libc doesn't
require exposing the interface for others to use.
However, I'm not talking about using this to build a libc-free std. I'm
talking about using this to build a libc-free *application*. (Which is
one reason I want this in core, not std.)
|
What would that value be? |
|
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. |
|
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
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. |
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
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 This is why I think
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. |
|
It was claimed that these APIs add value even if we were to stabilize I can't imagine What would that value be? because if we were to stabilize 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 |
|
@gnzlbg 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 |
|
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. |
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. |
|
If using |
|
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. |
|
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. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
rfcbot
added
the
finished-final-comment-period
|
The final comment period, with a disposition to close, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
rfcbot
removed
the
final-comment-period
|
Ok, I'm going to close this due to the FCP conclusion |
Based on the
syscallcrate. Right now onlyx86,x86-64,armandaarch64architectures 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 tocore::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