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

RFC: Target extension #2048

Open
wants to merge 57 commits into
base: master
from

Conversation

Projects
None yet
@semarie

semarie commented Jun 27, 2017

Rendered

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Aug 21, 2017

Contributor

@semarie could you consider signing off to the MIT/Apache 2.0 licensing terms inside this issue: #2096 ? Thanks!

Contributor

est31 commented Aug 21, 2017

@semarie could you consider signing off to the MIT/Apache 2.0 licensing terms inside this issue: #2096 ? Thanks!

@semarie

This comment has been minimized.

Show comment
Hide comment
@semarie

semarie Sep 21, 2017

@rust-lang/libs I would like to have some feedback on the RFC.

I consider outside the scope of this RFC to demonstrate why a particular alternative (like runtime detection) wouldn't be a good long term solution. I would like to prefer discussing that on a particular document related to the alternative (like another RFC proposition): it would be more simple for me to discuss on facts and statements, instead of just feeling.

I consider RFC process a way to target long term solution for Rust. The fact that implementing the RFC and makes it to be effectively used in infrastucture would take long time shouldn't being a problem for the RFC itself.

semarie commented Sep 21, 2017

@rust-lang/libs I would like to have some feedback on the RFC.

I consider outside the scope of this RFC to demonstrate why a particular alternative (like runtime detection) wouldn't be a good long term solution. I would like to prefer discussing that on a particular document related to the alternative (like another RFC proposition): it would be more simple for me to discuss on facts and statements, instead of just feeling.

I consider RFC process a way to target long term solution for Rust. The fact that implementing the RFC and makes it to be effectively used in infrastucture would take long time shouldn't being a problem for the RFC itself.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Sep 21, 2017

Member

cc @rust-lang/libs (only a member of a team can refer to theirs or any other team)

Member

eddyb commented Sep 21, 2017

cc @rust-lang/libs (only a member of a team can refer to theirs or any other team)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Sep 26, 2017

Member

The libs team discussed this briefly during triage today, but our conclusion is that we unfortunately just don't have the bandwidth to work through the design here at this time. We've always long wanted a "platform team" whose responsibility is porting Rust to all manner of platforms and ensuring it works well across them all, and this RFC hits squarely on what such a team work work with. We'd also be thrilled to have members of the *BSD community as part of this team!

With the impl period having recently started though it will likely be some time before we can begin to organize such a team and make progress on these sorts of questions. Our hope though is that near the beginning of 2018 we can start to organize such a team to tackle the problems such as those solved in this RFC.

Member

alexcrichton commented Sep 26, 2017

The libs team discussed this briefly during triage today, but our conclusion is that we unfortunately just don't have the bandwidth to work through the design here at this time. We've always long wanted a "platform team" whose responsibility is porting Rust to all manner of platforms and ensuring it works well across them all, and this RFC hits squarely on what such a team work work with. We'd also be thrilled to have members of the *BSD community as part of this team!

With the impl period having recently started though it will likely be some time before we can begin to organize such a team and make progress on these sorts of questions. Our hope though is that near the beginning of 2018 we can start to organize such a team to tackle the problems such as those solved in this RFC.

@dumbbell

This comment has been minimized.

Show comment
Hide comment
@dumbbell

dumbbell Dec 6, 2017

Hi!

I would like to add another example, still based on FreeBSD 12 (next major release) vs. previous branches. struct kevent, used by the kqueue(2) API, received several changes:

@@ -62,8 +66,9 @@ struct kevent {
        short           filter;         /* filter for event */
        unsigned short  flags;
        unsigned int    fflags;
-       __intptr_t      data;
+       __int64_t       data;
        void            *udata;         /* opaque user data identifier */
+       __uint64_t      ext[4];
 };

So:

  1. The data member changed type to become 64-bit on all platforms.
  2. There is a new ext member.

And thus, the API and the ABI were changed.

Now back to Rust: this structure is defined in libc but is initialized used in the mio crate. So patching the FreeBSD package of Rust isn't enough because mio is pulled in by Cargo. When built on FreeBSD 12, the crate obviously doesn't work: an executable using kqueue(2) (indirectly and implicitely through mio) hangs.

dumbbell commented Dec 6, 2017

Hi!

I would like to add another example, still based on FreeBSD 12 (next major release) vs. previous branches. struct kevent, used by the kqueue(2) API, received several changes:

@@ -62,8 +66,9 @@ struct kevent {
        short           filter;         /* filter for event */
        unsigned short  flags;
        unsigned int    fflags;
-       __intptr_t      data;
+       __int64_t       data;
        void            *udata;         /* opaque user data identifier */
+       __uint64_t      ext[4];
 };

So:

  1. The data member changed type to become 64-bit on all platforms.
  2. There is a new ext member.

And thus, the API and the ABI were changed.

Now back to Rust: this structure is defined in libc but is initialized used in the mio crate. So patching the FreeBSD package of Rust isn't enough because mio is pulled in by Cargo. When built on FreeBSD 12, the crate obviously doesn't work: an executable using kqueue(2) (indirectly and implicitely through mio) hangs.

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This fixes rustup and building from git (once libc is updated for bootstrap)
on FreeBSD 12 post-ino64 in freebsd/freebsd@f713b08.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand Rust
won't work at all on 12 without doing this currently.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility mode
by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit ino_t.

Fixes rust-lang/rust#42681

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This fixes rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler on FreeBSD12 to
build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

Fixes rust-lang/rust#42681

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This fixes rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler on FreeBSD12 to
build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
freebsd/freebsd@f713b08#diff-61a32fcfb7ecd4517665fed591813c57
and
freebsd/freebsd@f713b08#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

Fixes rust-lang/rust#42681

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This fixes rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
freebsd/freebsd@f713b08#diff-61a32fcfb7ecd4517665fed591813c57
and
freebsd/freebsd@f713b08#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

Fixes rust-lang/rust#42681

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This fixes rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
freebsd/freebsd@f713b08#diff-61a32fcfb7ecd4517665fed591813c57
and
freebsd/freebsd@f713b08#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc..

Fixes rust-lang/rust#42681

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This fixes rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
freebsd/freebsd@f713b08#diff-61a32fcfb7ecd4517665fed591813c57
and
freebsd/freebsd@f713b08#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc.  Only functions using dirent, stat, glob_t,
and dev_t need the changes.

Fixes rust-lang/rust#42681

bdrewery added a commit to bdrewery/libc that referenced this pull request Mar 1, 2018

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.
This follows the same method as other platforms like OSX and NetBSD.

This will fix rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
freebsd/freebsd@f713b08#diff-61a32fcfb7ecd4517665fed591813c57
and
freebsd/freebsd@f713b08#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc.  Only functions using dirent, stat, glob_t,
and dev_t need the changes.

Fixes rust-lang/rust#42681

bors added a commit to rust-lang/libc that referenced this pull request Mar 2, 2018

Auto merge of #937 - bdrewery:freebsd-ino64-compat, r=alexcrichton
Use pre-ino64 FreeBSD symbols to resolve binary compatibility.

This follows the same method as other platforms like OSX and NetBSD.

This will fix rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in freebsd/freebsd@f713b08.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
rust-lang/rfcs#2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
freebsd/freebsd@f713b08#diff-61a32fcfb7ecd4517665fed591813c57
and
freebsd/freebsd@f713b08#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc.  Only functions using dirent, stat, glob_t,
and dev_t need the changes.

Fixes rust-lang/rust#42681
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 12, 2018

Member

Returning to this RFC after some time now, I think that we may be able to make some progess on this perhaps? Not a whole lot has changed in the meantime other than rust-lang/libc#937, but I think that we would be able to accept this and improve the story (at least on nightly) for the BSD-like systems with a few changes. @semarie would you be ok with changes like this?

  • We won't be distributing multiple versions of libraries any time soon, so I think we'll want to scope this RFC back to only mention the BSD targets rather than also platforms like OSX.
  • Could the RFC explicitly list what version of FreeBSD/NetBSD targets will be shipped along with a small transition plan of how to get from where we are today to the targets-of-tomorrow?

With that I think we'd definitely be open to implementing an unstable version of this RFC (aka with the relevant #[cfg] matchers and whatnot).

Member

alexcrichton commented Mar 12, 2018

Returning to this RFC after some time now, I think that we may be able to make some progess on this perhaps? Not a whole lot has changed in the meantime other than rust-lang/libc#937, but I think that we would be able to accept this and improve the story (at least on nightly) for the BSD-like systems with a few changes. @semarie would you be ok with changes like this?

  • We won't be distributing multiple versions of libraries any time soon, so I think we'll want to scope this RFC back to only mention the BSD targets rather than also platforms like OSX.
  • Could the RFC explicitly list what version of FreeBSD/NetBSD targets will be shipped along with a small transition plan of how to get from where we are today to the targets-of-tomorrow?

With that I think we'd definitely be open to implementing an unstable version of this RFC (aka with the relevant #[cfg] matchers and whatnot).

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 12, 2018

Member

Oh also one aspect that came up during triage is that we may wish to leave out the comparators like version_le and such for now. Those can always be reimplemented in build scripts for the time being and otherwise would help trim this down a bit!

Member

alexcrichton commented Mar 12, 2018

Oh also one aspect that came up during triage is that we may wish to leave out the comparators like version_le and such for now. Those can always be reimplemented in build scripts for the time being and otherwise would help trim this down a bit!

@semarie

This comment has been minimized.

Show comment
Hide comment
@semarie

semarie Mar 14, 2018

@alexcrichton no problem to adapt the RFC.

Just a point, could you explain to me (or point to me an external document) about what you mean by stopping distributing multiple versions of libraries ? I am unsure to understand.

For the BSD version that should be supported, I think it is better than NetBSD and FreeBSD developers says what they expect and see if it is ok with Rust developers. I think difference should be done between "the code supports the version" and "Rust infrastructure provides a binary".

If I take OpenBSD as example, we only supports the two latest releases (and the current developpement HEAD). So it would be no sens for Rust to provides compatibility code for more than these. And it would be acceptable for me to have only latest release + HEAD supported in libc (for example). Regarding distribution (even if currently OpenBSD is tier-3 and no binary is distributed by Rust infrastructure) having only binary for latest release would be ok for me.

Please correct me if I didn't understand correctly something. Thanks.

semarie commented Mar 14, 2018

@alexcrichton no problem to adapt the RFC.

Just a point, could you explain to me (or point to me an external document) about what you mean by stopping distributing multiple versions of libraries ? I am unsure to understand.

For the BSD version that should be supported, I think it is better than NetBSD and FreeBSD developers says what they expect and see if it is ok with Rust developers. I think difference should be done between "the code supports the version" and "Rust infrastructure provides a binary".

If I take OpenBSD as example, we only supports the two latest releases (and the current developpement HEAD). So it would be no sens for Rust to provides compatibility code for more than these. And it would be acceptable for me to have only latest release + HEAD supported in libc (for example). Regarding distribution (even if currently OpenBSD is tier-3 and no binary is distributed by Rust infrastructure) having only binary for latest release would be ok for me.

Please correct me if I didn't understand correctly something. Thanks.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 14, 2018

Member

@semarie oh sure I mostly mean that currently we are building and shipping x86_64-unknown-freebsd on CI, and after this RFC we would continue to only build/ship one target per platforms (like we do today). We probably won't be doing multiple versions of FreeBSD in the near future, for example. The code, however, can of course have compatibility for everything!

Member

alexcrichton commented Mar 14, 2018

@semarie oh sure I mostly mean that currently we are building and shipping x86_64-unknown-freebsd on CI, and after this RFC we would continue to only build/ship one target per platforms (like we do today). We probably won't be doing multiple versions of FreeBSD in the near future, for example. The code, however, can of course have compatibility for everything!

semarie added some commits Apr 13, 2018

Restrict the RFC to BSD OS
while in motivation section, update some historical points (some OS
version are released now)
Remove predicates from the RFC.
Only mention them as solution of possible drawbacks (long enumeration of
versions).
FreeBSD 12 is partially supported
under FreeBSD 12, libc uses FreeBSD 11 compat ABI. It limits `ino_t` to
32 bits (and uses truncation for not representable ino_t on 32 bits).
@semarie

This comment has been minimized.

Show comment
Hide comment
@semarie

semarie Apr 14, 2018

@alexcrichton I think the most important change concerns the addition of the migration path section. The intent is to take globally all changes and impacts involved in the implementation of this RFC regarding the whole Rust ecosystem, step by step.

Comments would be welcome, in under to ensure I meet your expectations.

semarie commented Apr 14, 2018

@alexcrichton I think the most important change concerns the addition of the migration path section. The intent is to take globally all changes and impacts involved in the implementation of this RFC regarding the whole Rust ecosystem, step by step.

Comments would be welcome, in under to ensure I meet your expectations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment