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

rust: Eschew Box<MaybeUninit<T>>::write #1106

Conversation

workingjubilee
Copy link

T-libs-api has consensus for stabilizing some of feature(new_uninit), but not for Box<MaybeUninit<T>>::write. The replacement is trivial, so let's just do that, and RfL can simply move off the feature after it is stabilized. That will happen immediately after this unblocks Rust CI, as the relevant FCP has completed:

rust-lang/rust#63291 (comment)

This is required in advance of the stabilization because any remaining unstable API will be carved up into subfeatures as a direct result of stabilizing the majority of it. This code doesn't know about those yet. It can't, as they haven't landed, as building this code blocks Rust's CI but the expected-to-be-stabilized API can't be stabilized as long as this code requires that feature.

T-libs-api has consensus for stabilizing some of `feature(new_uninit)`,
but not for `Box<MaybeUninit<T>>::write`. The replacement is trivial, so
let's just do that, and RfL can simply move off the feature after it is
stabilized. That will happen immediately after this unblocks Rust CI,
as the relevant FCP has completed:

rust-lang/rust#63291 (comment)

This is required in advance of the stabilization because any remaining
unstable API will be carved up into subfeatures as a direct result of
stabilizing the majority of it. This code doesn't know about those yet.
It can't, as they haven't landed, as building this code blocks Rust's CI
but the expected-to-be-stabilized API can't be stabilized as long as
this code requires that feature.

Signed-off-by: Jubilee Young <[email protected]>
@tgross35
Copy link
Collaborator

This looks reasonable to me but it does need to go through the list. Are you able to send it or would you prefer one of us forward it for you?

@workingjubilee
Copy link
Author

which one tho'

@tgross35
Copy link
Collaborator

Just the default [email protected], with the CCs here

linux/MAINTAINERS

Lines 19907 to 19917 in 6d1c22d

RUST
M: Miguel Ojeda <[email protected]>
M: Alex Gaynor <[email protected]>
M: Wedson Almeida Filho <[email protected]>
R: Boqun Feng <[email protected]>
R: Gary Guo <[email protected]>
R: Björn Roy Baron <[email protected]>
R: Benno Lossin <[email protected]>
R: Andreas Hindborg <[email protected]>
R: Alice Ryhl <[email protected]>
L: [email protected]

@workingjubilee
Copy link
Author

I would never have guessed to send it to that specific list so there's nothing "default" about it.

@tgross35
Copy link
Collaborator

Heh by default I guess I just meant whatever get-maintainer.pl would have said. But yeah, that's the main list for anything rust related (archives at https://lore.kernel.org/rust-for-linux/)

@workingjubilee
Copy link
Author

...Why does the kernel document mailing list procedure in the kernel's source docs, instead of somewhere linked from the various webpages touting to be the LKML FAQ?

It was a stroke of luck that I got Kconfig to work to test this at all. I'm honestly kind of baffled that something like cd rust && make check or cd rust && make help doesn't do something sensible, honestly.

@workingjubilee
Copy link
Author

...Why does the kernel document mailing list procedure in the kernel's source docs, instead of somewhere linked from the various webpages touting to be the LKML FAQ?

I mean, I can understand the chain of events that does lead to the placement making more sense, I just can't understand not e.g. decommissioning http://vger.kernel.org/lkml/#s4 posthaste. Surely the Linux Foundation can afford sufficient devops assassins to put out a hit on a rogue HTML file?

@tgross35
Copy link
Collaborator

Fwiw I think https://docs.kernel.org/process/submitting-patches.html is the place most people get pointed now, I don't think I have ever seen the FAQ you posted. I don't disagree that figuring out the emails is about the worst part of kernel development, I still struggle to reply to emails that aren't already in my inbox (just subscribing to every list is easier than setting up Mutt, lol).

If it helps, usually the process looks something like:

# Get a .patch file for the last 1 commit
git format-patch -1

# List of people to mail
scripts/get_maintainer.pl 0001-my-thing.patch --norolestats

# Send it, usually `to:` the maintianers and `cc:` the lists and everyone else
# from the output above. There's a `--dry-run` option to try first
git send-email --to='...' --cc='...' ... 0001-my-thing.patch

@tgross35
Copy link
Collaborator

If it's still giving you problems then one of us can forward it for you fine, not trying to put you in mailing list pain because you made the mistake of being helpful. But usually it's pretty straightforward to send it.

But the Rust build options are indeed pretty hidden, lots of looking at the target dependencies in menuconfig unfortunately. Hopefully that will get better as we stop requiring a lot of tiny things to be turned off.

@workingjubilee
Copy link
Author

I will simply remain surprised there's no equivalent of make check or make rustcheck!

@workingjubilee
Copy link
Author

workingjubilee commented Aug 23, 2024

And I will take a quick look at the patch formatting before deciding whether to put you up to it, I had to finish filing a form with a Byzantine bureaucracy first (I've done this before and my main annoyance, that I remember, was trying to make sure that it was an ASCII patch or whatever).

@workingjubilee
Copy link
Author

There, sent to the mailing list.

@ojeda
Copy link
Member

ojeda commented Aug 23, 2024

Thanks for your feedback @workingjubilee! I have forwarded it to the admins (for the vger one in particular, perhaps they can do something about it), but please note that most of these involve changes for most of the kernel, so they aren't things we can tackle independently.

which one tho'

We have some docs of our own at https://rust-for-linux.com/contributing, with links to the relevant kernel docs and some other tips. https://kernel.org has also a link to the docs, https://docs.kernel.org, which explains how to interact with the kernel.

...Why does the kernel document mailing list procedure in the kernel's source docs, instead of somewhere linked from the various webpages touting to be the LKML FAQ?

Hmm... I am not sure I understand. It is common to document your project/workflow/... in the same tree as the sources (or at least having a pointer to somewhere from there).

I mean, I can understand the chain of events that does lead to the placement making more sense, I just can't understand not e.g. decommissioning http://vger.kernel.org/lkml/#s4 posthaste. Surely the Linux Foundation can afford sufficient devops assassins to put out a hit on a rogue HTML file?

I think the vger server was an older one, managed differently, and perhaps it has something to do with that. But, yeah, the document is quite old so perhaps it can be updated or archived.

It was a stroke of luck that I got Kconfig to work to test this at all. I'm honestly kind of baffled that something like cd rust && make check or cd rust && make help doesn't do something sensible, honestly.

make help works. Perhaps the kernel could print a message to redirect people somewhere else for make check in case someone expects that target to exist due to other software (e.g. GNU).

And I will take a quick look at the patch formatting before deciding whether to put you up to it, I had to finish filing a form with a Byzantine bureaucracy first (I've done this before and my main annoyance, that I remember, was trying to make sure that it was an ASCII patch or whatever).

Yes, the kernel uses a mailing list workflow, for better or worse.

@workingjubilee
Copy link
Author

make help works. Perhaps the kernel could print a message to redirect people somewhere else for make check in case someone expects that target to exist due to other software (e.g. GNU).

cd rust && make help does not.

@workingjubilee
Copy link
Author

$ cd rust
$ make check
make: *** No rule to make target 'check'.  Stop.
$ make help
make: *** No rule to make target 'help'.  Stop.

@ojeda
Copy link
Member

ojeda commented Aug 24, 2024

cd rust && make help does not.

I am aware -- I said make help works because you said cd rust && make help does not.

@workingjubilee workingjubilee deleted the initialize-my-box-maybe branch August 30, 2024 01:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants