Add the libstd-modifications needed for the L4Re target #43972

TobiasSchaffner · 2017-08-18T08:26:23Z

This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re).

A target for the L4Re was introduced in commit: c151220

In many aspects implementations for linux also apply for the L4Re microkernel.

Some uncommon characteristics had to be resolved:

L4Re has no network funktionality
L4Re has a maximum stacksize of 1Mb for threads
L4Re has no uid or gid

Co-authored-by: Sebastian Humenda sebastian.humenda@tu-dresden.de

rust-highfive · 2017-08-18T08:26:36Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

kennytm · 2017-08-18T08:56:13Z

src/libstd/sys_common/util.rs

+
+    // L4Re is not able to handle more than 1MB.
+    #[cfg(target_os = "l4re")]
+    let amt = amt.unwrap_or(1 * 1024 * 1024);


Unfortunately tidy disallows you from writing this using #[cfg] or cfg!(). See https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/pal.rs for detail.

[00:03:46] tidy error: /checkout/src/libstd/sys_common/util.rs:26: platform-specific cfg: cfg(not(target_os = "l4re")) [00:03:46] tidy error: /checkout/src/libstd/sys_common/util.rs:30: platform-specific cfg: cfg(target_os = "l4re")

TobiasSchaffner · 2017-08-18T10:02:59Z

Thanks for the explanation!

alexcrichton · 2017-08-18T17:18:43Z

I think l4re is classified as "target family is unix", but maybe with these #[cfg] annotations we should go the other way around? Is l4re "unix enough" to still warrant such a classification?

humenda · 2017-08-18T19:40:56Z

In the strict sense, L4(Re) is a microkernel with almost all of the components
implemented in user space; traditional Unixes have a monolithic kernel and a smaller user space. On top of the completely different API, L4Re has a POSIX(-alike) personality for backward compatibility featured by uClibc. So for most programs, L4Re looks like a normal (uClibc) Unix, just without networking. I am pretty sure that not classifying L4Re as unixoid would mean substantially more work which wouldn't really pay off. Most of the software ports to L4Re go down the Unix path, too.

TobiasSchaffner · 2017-08-20T21:10:41Z

Id like to add that we needed less #[cfg] annotations than any other unix family member. In many cases (for example with the set_name function in thread.rs) you need one annotation to choose one of the implementations. That leads to a number of #cfg annotations that is always needed when implementing a new target for unix.

alexcrichton · 2017-08-22T14:59:01Z

src/libstd/sys/unix/thread.rs

+
+        // L4Re only supports a maximum of 1Mb per default.
+        #[cfg(target_os = "l4re")]
+        let stack_size = cmp::min(stack_size, 1024 * 1024);


Shouldn't we rely on pthread_create to return an error for larger stack sizes here?

It will run in an error when pthread_attr_setstacksize is called. (sys/unix/thread.rs line: 55)
Most systems do not have a fixed maximum. We tried to put it to to the point where also the minimum size is checked. Putting it to the pthread_attr_setstacksize check would in my opinion put to much complexity there.

The standard library tends to prefer to expose the underlying platform semantics as much as possible, avoiding trying to make shims and such where possible. It sounds like the default stack size on l4re should be less, but I believe we should still let the error propagate from pthread_attr_setstacksize

@humenda would it be possible to change the min_stack_size function instead of adding this clause here?

alexcrichton · 2017-08-22T14:59:41Z

src/libstd/lib.rs

@@ -469,6 +469,7 @@ pub mod error;
 pub mod ffi;
 pub mod fs;
 pub mod io;
+#[cfg(not(target_os = "l4re"))]


This is my main hesitation for this PR, just excluding the net module. This, AFAIK, doesn't happen on any other platform.

I see your point and I know that it is unusual. As Sebastian already mentioned "L4Re looks like a normal (uClibc) Unix, just without networking". Implementing a completely new platform would lead to large amounts of redundant code while we are able to (even if it is unusual) can completely disable the net part with three statements.

It's ok to not have networking implemented, Emscripten for example doesn't implement threads. To do this, however, the shims in the sys module should all return errors on l4re instead of being compiled away.

humenda · 2017-08-22T21:27:46Z

I see your point about completely removing networking, but on the other hand, how many platforms does Rust current target which don't have networking? Using the uClibc functions for networking on L4Re is undefined behaviour, there's no notion of networking. IMHO, the cleanest solution is the removal. If you don't agree, please help us to find a different solution. Thanks

alexcrichton · 2017-08-23T15:49:42Z

@humenda oh so right now the conventional design of libstd is that it doesn't tailor the top-level API available per-platform, it's always there unconditionally 100% of the time. This may change in the future, but for now it's the status quo that needs to be maintained.

It's fine to not call libc functions and instead just return errors in Rust.

aidanhs · 2017-08-31T14:27:18Z

Hi @TobiasSchaffner, are you able to make the changes as @alexcrichton suggests, i.e. probably just making the net module a skeleton that always errors?

TobiasSchaffner · 2017-09-01T06:51:48Z

Hi @aidanhs, I am on vacation until 1st of October. Maybe @humenda will work on a change in the meantime.

humenda · 2017-09-01T07:07:11Z

Hi @@aidhans I'll take a look at the weekend or at Monday. Cheers

As suggested in the discussion of PR rust-lang#43972, std should provide a uniform API to all platforms. Since there's no networking on L4Re, this now is a module in `sys::net` providing types and functions/methods returning an error for each action.

humenda · 2017-09-06T14:31:13Z

@alexcrichton Could you please have a look at the changes?
Please note that they won't build before https://github.com/rust-lang/libc/pull/758 hasn't been merged.
Thanks!

alexcrichton · 2017-09-06T19:58:59Z

Thanks! Want to update the libc submodule now as well?

humenda · 2017-09-07T19:13:23Z

@alexcrichton I moved the line to the `min_stack_size` function in `util.rs`, although I don't like the change. `min_stack_size` suggests that it returns the minimum. It doesn't do so for other platforms. 2M is certainly not the minimum for Linux and returning 1M for L4Re is the maximum for this platform. However, it'll work.

alexcrichton · 2017-09-07T21:18:15Z

Looks good to me! Appears to be a rebase conflict though?

* Match definition of c_char in os/raw.rs with the libc definition Due to historic reasons, os/raw.rs redefines types for c_char from libc, but these didn't match. Now they do :). * Enable signal reset on exec for L4Re L4Re has full signal emulation and hence it needs to reset the signal set of the child with sigemptyset. However, gid and uid should *not* be set.

This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re). A target for the L4Re was introduced in commit: c151220 In many aspects implementations for linux also apply for the L4Re microkernel. Two uncommon characteristics had to be resolved: * L4Re has no network funktionality * L4Re has a maximum stacksize of 1Mb for threads Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>

As suggested in the discussion of PR rust-lang#43972, std should provide a uniform API to all platforms. Since there's no networking on L4Re, this now is a module in `sys::net` providing types and functions/methods returning an error for each action.

alexcrichton · 2017-09-08T14:00:38Z

@bors: r+

bors · 2017-09-08T14:00:39Z

📌 Commit 5d1a9d7 has been approved by alexcrichton

alexcrichton · 2017-09-08T18:23:46Z

src/libstd/sys/redox/thread.rs

@@ -89,3 +91,18 @@ pub mod guard {
    pub unsafe fn current() -> Option<usize> { None }
    pub unsafe fn init() -> Option<usize> { None }
 }
+
+pub fn min_stack() -> usize {


Instead of duplicating all this logic in all the various platforms, could just the default min stack size get implemented on various platforms?

TobiasSchaffner · 2017-09-12T09:41:42Z

r? @alexcrichton

alexcrichton · 2017-09-12T14:24:57Z

src/libstd/sys/unix/thread.rs

+#[cfg(not(target_os = "l4re"))]
+pub const default_min_stack_size: usize = 2 * 1024 * 1024;
+#[cfg(target_os = "l4re")]
+pub const default_min_stack_size: usize = 1024 * 1024;


Conventionally in rust constants have full uppercase names like DEFAULT_MIN_STACK_SIZE

The default min stack size value is smaller on l4re and therefore this value has to be different depending on the platform.

alexcrichton · 2017-09-13T13:59:10Z

@bors: r+

bors · 2017-09-13T13:59:11Z

📌 Commit b2b5063 has been approved by alexcrichton

bors · 2017-09-14T00:21:57Z

⌛ Testing commit b2b5063 with merge 991066932ac6e7cfb76ec0c920867134d219811b...

bors · 2017-09-14T00:28:23Z

💔 Test failed - status-travis

alexcrichton · 2017-09-14T01:39:38Z

@bors: retry

???

bors · 2017-09-14T03:03:04Z

⌛ Testing commit b2b5063 with merge 84bbd14...

Add the libstd-modifications needed for the L4Re target This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re). A target for the L4Re was introduced in commit: c151220 In many aspects implementations for linux also apply for the L4Re microkernel. Some uncommon characteristics had to be resolved: * L4Re has no network funktionality * L4Re has a maximum stacksize of 1Mb for threads * L4Re has no uid or gid Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>

bors · 2017-09-14T06:08:46Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 84bbd14 to master...

rust-highfive assigned alexcrichton Aug 18, 2017

kennytm reviewed Aug 18, 2017

View reviewed changes

TobiasSchaffner force-pushed the std_clean branch from a2f2f7b to 1224c5f Compare August 18, 2017 09:36

TobiasSchaffner force-pushed the std_clean branch from 1224c5f to 5089909 Compare August 18, 2017 10:15

alexcrichton reviewed Aug 22, 2017

View reviewed changes

arielb1 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 22, 2017

humenda and others added 5 commits September 8, 2017 14:36

Move the stack size value for L4Re to the min_stack_size function

40794bf

Update liblibc submodule to include latest uclibc changes

5d1a9d7

TobiasSchaffner force-pushed the std_clean branch from 242e4c4 to 5d1a9d7 Compare September 8, 2017 12:38

alexcrichton reviewed Sep 8, 2017

View reviewed changes

TobiasSchaffner force-pushed the std_clean branch from fea627c to 0f8c9d7 Compare September 9, 2017 09:13

alexcrichton reviewed Sep 12, 2017

View reviewed changes

Move default stack min size to thread implementations

b2b5063

The default min stack size value is smaller on l4re and therefore this value has to be different depending on the platform.

humenda force-pushed the std_clean branch from 0f8c9d7 to b2b5063 Compare September 13, 2017 08:57

bors merged commit b2b5063 into rust-lang:master Sep 14, 2017

This was referenced Sep 14, 2017

Rollup of 20 pull requests #44561

Closed

Implement named threads on Windows (v2) #44374

Merged

{compiler-builtins,libc} shim cleanup #44515

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add the libstd-modifications needed for the L4Re target #43972

Add the libstd-modifications needed for the L4Re target #43972

TobiasSchaffner commented Aug 18, 2017

rust-highfive commented Aug 18, 2017

kennytm Aug 18, 2017

TobiasSchaffner commented Aug 18, 2017 •

edited

Loading

alexcrichton commented Aug 18, 2017

humenda commented Aug 18, 2017

TobiasSchaffner commented Aug 20, 2017 •

edited

Loading

alexcrichton Aug 22, 2017

TobiasSchaffner Aug 22, 2017

alexcrichton Aug 22, 2017

alexcrichton Sep 6, 2017

alexcrichton Aug 22, 2017

TobiasSchaffner Aug 22, 2017

alexcrichton Aug 22, 2017

humenda commented Aug 22, 2017 via email

alexcrichton commented Aug 23, 2017

aidanhs commented Aug 31, 2017

TobiasSchaffner commented Sep 1, 2017 via email •

edited

Loading

humenda commented Sep 1, 2017 via email

humenda commented Sep 6, 2017

alexcrichton commented Sep 6, 2017

humenda commented Sep 7, 2017 via email

alexcrichton commented Sep 7, 2017

alexcrichton commented Sep 8, 2017

bors commented Sep 8, 2017

alexcrichton Sep 8, 2017

TobiasSchaffner commented Sep 12, 2017

alexcrichton Sep 12, 2017

alexcrichton commented Sep 13, 2017

bors commented Sep 13, 2017

bors commented Sep 14, 2017

bors commented Sep 14, 2017

alexcrichton commented Sep 14, 2017

bors commented Sep 14, 2017

bors commented Sep 14, 2017

Add the libstd-modifications needed for the L4Re target #43972

Add the libstd-modifications needed for the L4Re target #43972

Conversation

TobiasSchaffner commented Aug 18, 2017

rust-highfive commented Aug 18, 2017

Choose a reason for hiding this comment

TobiasSchaffner commented Aug 18, 2017 • edited Loading

alexcrichton commented Aug 18, 2017

humenda commented Aug 18, 2017

TobiasSchaffner commented Aug 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

humenda commented Aug 22, 2017 via email

alexcrichton commented Aug 23, 2017

aidanhs commented Aug 31, 2017

TobiasSchaffner commented Sep 1, 2017 via email • edited Loading

humenda commented Sep 1, 2017 via email

humenda commented Sep 6, 2017

alexcrichton commented Sep 6, 2017

humenda commented Sep 7, 2017 via email

alexcrichton commented Sep 7, 2017

alexcrichton commented Sep 8, 2017

bors commented Sep 8, 2017

Choose a reason for hiding this comment

TobiasSchaffner commented Sep 12, 2017

Choose a reason for hiding this comment

alexcrichton commented Sep 13, 2017

bors commented Sep 13, 2017

bors commented Sep 14, 2017

bors commented Sep 14, 2017

alexcrichton commented Sep 14, 2017

bors commented Sep 14, 2017

bors commented Sep 14, 2017

TobiasSchaffner commented Aug 18, 2017 •

edited

Loading

TobiasSchaffner commented Aug 20, 2017 •

edited

Loading

TobiasSchaffner commented Sep 1, 2017 via email •

edited

Loading