Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Apr 16, 2025 at 5:36 PM Ben Hutchings wrote: > > I don't see why there would be a problem with mixing objects built using > native and cross- C compilers with the same target and version. (Unless > you enable gcc plugins, which we don't.) It may work, but as far as I was told, it is not

Re: Package for development of out-of-tree kernel modules written in Rust

On Sun, Apr 13, 2025 at 5:36 PM NoisyCoil wrote: > > 1. Native build on arm64. Installed the build on amd64, replaced the > Rust files (rmeta and libmacros) with ones obtained by cross-compiling > the same kernel with the same config on amd64. Pointing KDIR to the > natively-built /usr/src/linux-h

Re: Package for development of out-of-tree kernel modules written in Rust

On Fri, Apr 4, 2025 at 11:00 AM Bastian Blank wrote: > > C macros are read by the preprocessor shipped in the compiler. The > preprocessor changes it's behaviour depending on the input files. > However you don't recompile the preprocessor depending on the kernel > config. I am aware of how C mac

Re: Package for development of out-of-tree kernel modules written in Rust

On Thu, Apr 3, 2025 at 11:32 PM NoisyCoil wrote: > > I think the key issue here is Debian wants to support cross-compiling > out-of-tree kernel modules, I see, that sentence explains it, thanks! So you want to build a kernel for architecture X in a host of architecture Y, and then build an out-o

Re: Package for development of out-of-tree kernel modules written in Rust

On Thu, Apr 3, 2025 at 8:33 PM Bastian Blank wrote: > > What the heck is this good for, where config dependency would be useful? C macros in the kernel use the kernel config all the time, why would this be different? What is the root issue here? > So, either "macros" is static and unchanging, t

Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Feb 26, 2025 at 9:58 PM NoisyCoil wrote: > > 2. it relieves packagers from having to manually keep track of what must > be installed, especially if whether they are generated or not depends on > the config (I think this is not the case right now, but I don't see why > it couldn't be in the

Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Feb 26, 2025 at 8:12 PM NoisyCoil wrote: > > the case, then I would also ask Miguel if the .rmeta files can be used > from another architecture for cross-compiling. I think the .rmeta files > can only be used with the same rustc that compiled the kernel crates? > Don't know exactly which c

Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Feb 26, 2025 at 7:24 PM NoisyCoil wrote: > > It does indeed depend on the configuration, because at least some > abstractions are enabled via the configuration and different metadata > will be produced depending on whether they are or not (Miguel should > confirm this, but I'm pretty sure

Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Feb 26, 2025 at 7:11 PM Ben Hutchings wrote: > > This shouldn't go in a linux-headers package, because we aim to support > cross-builds of modules. If it doesn't depend on the kernel > configuration (aside from CONFIG_RUST being enabled) then it belongs in > linux-kbuild. Hmm... Right no

Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Feb 26, 2025 at 3:15 PM NoisyCoil wrote: > > Yeah I'd imagined this could happen. Currently d/rules just copies > rust/{*.rmeta,*.so} into the destination directory. My guess was that in > the future they could be placed in subdirectories of rust/, but on a > second thought I think as subs

Re: Package for development of out-of-tree kernel modules written in Rust

On Wed, Feb 26, 2025 at 1:13 PM NoisyCoil wrote: > > As for the actual contents of the package, the Rust bits, they are > binary files (and include an actual shared library), so my reasoning was > that they should belong to a different package than > linux-headers-@abiname@@localversion@, and be i

Re: Rust for Linux and host-only libraries

On Fri, Apr 19, 2024 at 10:34 PM Fabian Grünbichler wrote: > > No, the patches are already applied in the source files shipped by > librust-xxx-dev, if there are any. The cargo wrapper takes care of other > things, like instructing cargo to use the packaged sources and setting > rustflags and s

Re: Rust for Linux and host-only libraries

On Fri, Apr 19, 2024 at 8:13 PM Fabian Grünbichler wrote: > > Yes, all crates packaged by the Rust team (and most packaged for consumption > by other packages/as build-deps by people outside of the team) ship their > (patched for distro use) sources in a subdir there. The patches (except for >

Rust for Linux and host-only libraries

Hi Ximin, Sylvestre, Fabian, all, In Rust for Linux, we are considering using host-only/userspace Rust libraries (e.g. `syn`), and we were asked to check whether it would be possible to just pick them from the distribution (since, in principle, they don't require kernel-specific changes). What is