Make it possible to write modules in stable Rust

[geofft]

Even though you'll need the unstable compiler for a while for this crate, modules themselves should be possible to write in stable Rust, in the same way that libstd itself requires unstable but can be used from stable Rust.

Right now hello-world uses #![feature(alloc)] to use alloc::borrow::ToOwned and alloc::String. Both alloc::borrow and alloc::string are stably re-exported in libstd. So we should do the same thing. Strictly speaking, this permits those modules to change as long as libstd makes an API-compatible facade, but practically that's unlikely to happen and if it does we can just steal whatever facade libstd comes up with (or in the worst case, take a semver hit).

Potentially the way to do this is to re-export a module named std that contains a subset of what's in actual libstd, with the intention of consumers doing

#[macro_use]
extern crate linux_kernel_module;
use linux_kernel_module::std;
use linux_kernel_module::std::prelude::v1::*;

That way, those things from std that do/can exist in kernelspace can just be used like normal.

[alex]

I wonder if we should file a bug with cargo-xbuild asking for the ability for a target to provide an alternate prelude. Would that make sense?

…

On Thu, May 31, 2018 at 11:45 PM Geoffrey Thomas ***@***.***> wrote: Even though you'll need the unstable compiler for a while for this crate, modules themselves should be possible to write in stable Rust, in the same way that libstd itself requires unstable but can be used from stable Rust. Right now hello-world uses #![feature(alloc)] to use alloc::borrow::ToOwned and alloc::String. Both alloc::borrow and alloc::string are stably re-exported in libstd. So we should do the same thing. Strictly speaking, this permits those modules to change as long as libstd makes an API-compatible facade, but practically that's unlikely to happen and if it does we can just steal whatever facade libstd comes up with (or in the worst case, take a semver hit). Potentially the way to do this is to re-export a module named std that contains a subset of what's in actual libstd, with the intention of consumers doing #[macro_use] extern crate linux_kernel_module; use linux_kernel_module::std; use linux_kernel_module::std::prelude::v1::*; That way, those things from std that do/can exist in kernelspace can just be used like normal. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBHWmkkNxUA6jNTU-uTcla_y9erq9ks5t4LjcgaJpZM4UWDlW> .

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

[geofft]

I tried playing around with #[feature(prelude_import)] but I couldn't get it to work... probably it only works with libcore and libstd specifically, I didn't source-dive rustc hard enough to find out.

A slightly more compelling thing would be for a target to provide an alternate libstd, which means that third-party crates that aren't no_std because they need liballoc could work (collection types, things that use a Vec, etc.)

[geofft]

Since alloc is stable, we're now down to just #[feature(const_str_as_bytes)] for modinfo. Keep in mind that modinfo doesn't even work in its present form anyway (#80)....

[alex]

That feature is going stable soon fwiw

…

On Sun, Sep 8, 2019, 1:44 PM Geoffrey Thomas ***@***.***> wrote: Since alloc is stable, we're now down to just #[feature(const_str_as_bytes)] for modinfo. Keep in mind that modinfo doesn't even work in its present form anyway (#80 <#80>).... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37?email_source=notifications&email_token=AAAAGBDN5TK6CENGWYHLLGLQIVB2RA5CNFSM4FCYHFLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FWXYQ#issuecomment-529230818>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAGBHVDGRATNIDBXALL4DQIVB2RANCNFSM4FCYHFLA> .

[geofft]

Oh hey, this has been fixed since #207!

[geofft]

Well, I forgot that -Z build-std=core,alloc is unstable. But that feels very similar to the fact that you need nightly for the linux-kernel-module-rust dependency itself, I think it's enough to say that there's no feature gates in the source code of modules.