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

linux: add a few kTLS defintions #3287

Merged
merged 1 commit into from Jul 16, 2023
Merged

linux: add a few kTLS defintions #3287

merged 1 commit into from Jul 16, 2023

Conversation

gennyble
Copy link
Contributor

related: nix-rust/nix#2065

i think android has support, too, but if I put it in linux-like does that imply emscripten support?

@rustbot
Copy link
Collaborator

rustbot commented Jun 30, 2023

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

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@fasterthanlime
Copy link

Thanks @gennyble for opening this!

I need this PR + a point release to (ultimately) land nix-rust/nix#2065 which in turn unblocks doing in-kernel TLS properly from rust with tokio, cf. bearcove/ktls#26

(I know, exciting!)

@gennyble
Copy link
Contributor Author

gennyble commented Jun 30, 2023

TLS_GET_RECORD_TYPE is from a kernel header which might not be available where libc is built. What would you like me to do here?

I see a skip might be an option?

@fasterthanlime
Copy link

@JohnTitor would it be possible to get a look at this? Maybe from another maintainer, if you're not able to?

@JohnTitor
Copy link
Member

TLS_GET_RECORD_TYPE is from a kernel header which might not be available where libc is built. What would you like me to do here?

I see a skip might be an option?

Correct.

@gennyble
Copy link
Contributor Author

Instead of skipping I added the header to the linux kernel headers for libc-test.

@rustbot review

@JohnTitor
Copy link
Member

Cool, thanks! @bors r+

@bors
Copy link
Contributor

bors commented Jul 16, 2023

📌 Commit 94cfcd2 has been approved by JohnTitor

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jul 16, 2023

⌛ Testing commit 94cfcd2 with merge af676d1...

@bors
Copy link
Contributor

bors commented Jul 16, 2023

☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing af676d1 to main...

@bors bors merged commit af676d1 into rust-lang:main Jul 16, 2023
11 checks passed
@fasterthanlime
Copy link

Thanks for getting this merged! When can we expect this to be included in a crates.io release of libc ? (So we can bump the version nix relies on)

@fasterthanlime
Copy link

fasterthanlime commented Sep 12, 2023

@JohnTitor the latest libc release was cut on June 25, 2023 - I think this means this PR still isn't on crates.io? The problem is we're trying to use those new additions from https://lib.rs/crates/nix, so a git dependency isn't really an option here.

Edit: opened #3350 to track this

Edit 2: @joshtriplett released 0.2.148 just now.

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

Successfully merging this pull request may close these issues.

None yet

5 participants