[Suggestion] An organization for the Rust-in-Linux effort

[ojeda]

@alex asked about the requirements for eventually merging something into the kernel in alex/linux#3 (comment)

While there are advantages of developing within the kernel (e.g. nowadays we have staging), this would be a treewide effort, not to mention multi-repo. To submit any changes to the kernel eventually, ideally everything required should be in stable Rust and a clean patch series is prepared for submission where everyone can discuss it in the LKML.

Therefore, in order to prepare everything, it would be nice to have something like the ClangBuiltLinux organization for all the Rust-in-Linux (Rust-for-Linux?) related things:

• The Linux fork with the framework and any other changes required (e.g. like those @alex started), plus a branch with an example driver, etc.
• A rustc fork (and any others) with all the features needed to build the Linux fork until they are in the official repo(s) (e.g. cargo xbuild as @joshtriplett mentioned)
• The CI setup
• etc.

[joshtriplett]

Sounds great to me! Such an organization could also include branches with ports of various APIs (filesystem, char device, etc), documentation (including rustdoc), experimental branches for cross-language LTO, a port of alloc...

[geofft]

I think I'd prefer to keep this repo at fishinabarrel since that's the URL we've been publishing. fishinabarrel is an org, so we can host other necessary forks here. @alex what do you think?

The work on alex/linux is experimental, once we get something that works at all we'll move it here.

[ojeda]

Of course, that goes without saying, this repository is your work after all! I was thinking more long term, specially if more people join up from different domains/companies/projects (Rust, Linux, LLVM, Google, Intel...).

I sent a handful of invitations as Owners like it was done for ClangBuiltLinux, so feel free to set it up however you see fit or delete if the effort does not take off.

[joshtriplett]

@geofft Note that if you move a repository in github, github will provide a redirect so that the URL keeps working, including for people who git clone that URL.

It's your call where you want to keep it, but the URL shouldn't be a factor.

[alex]

I don't think a full organization is necessary. From my perspective the goal should be to upstream:

• Anything needed in rustc/cargo for this to work stably
• The build system pieces to the kernel build system so you can build Rust code packaged with cargo

The actual bindings and APIs that you see in this repo should not be upstreamed to the kernel itself, until they're much more stable and have seen more production use (or there's interest in using them for in-tree modules).

Do folks disagree with this scoping? For me, given this scoping, I don't think there's a need for Kernel-Modules-on-Rust forks of these things, because none of them should be long-lived forks.

PS: I'm extremely excited so many other folks are interested, and we're delighted to work with folks on making this successful!

[ojeda]

I was indeed talking about in-tree modules and overall Rust support in mainline, which will require bindings and APIs as you mention. That is why I consider it a major effort!

I don't think we should add build support for a new language to the kernel if there are no in-tree users nor facilities for it. The reason is the usual one: if there is someone is building an outside-tree module, that same entity can also patch the kernel sources as needed to build it. Otherwise, it would be a maintenance burden on the kernel side and it would create development friction on the Rust for Linux side because any fix/improvement would need to go through the Linux process.

In my view, the plan should be to prepare a proof of concept with everything needed. Ideally this would include a handful of (small) drivers properly ported and shown to work smoothly. These drivers should showcase the advantages of Rust in the kernel and show how a real driver would look like in comparison to the C version. At that point, the work can be submitted as an RFC for the general kernel community to discuss and have a reasonable chance to have it eventually accepted.

[alex]

Ok, I'm glad I clarified on scope!

Yes, if that's the scope this proposal makes much more sense!

The scope I selected was based on the feedback I'd gotten from Kees Cook at LSS last week, and some other folks, where there seemed to be interest in build system support as a necessary first step.

[alex]

Would it be helpful to create a mailing list around this effort, or are folks happy coordinating with Github exclusively?

[joshtriplett]

On September 1, 2019 7:44:27 AM PDT, Alex Gaynor ***@***.***> wrote: Would it be helpful to create a mailing list around this effort, or are folks happy coordinating with Github exclusively?

I'd be happy using the Rust internals Discourse for this, along with the Rust Discord for real-time conversations.

[ojeda]

The suggested organization is at Rust for Linux. To start it up, I configured a few trivial things including a small webpage with links (following what ClangBuiltLinux did) plus a project to track the early efforts in the different repos/places/orgs.

Ah, and the logo, of course! ;)