Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86145 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Package for development of out-of-tree kernel modules written in Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 01:30 +0100
    Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-02-26 12:50 +0100
      Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 13:20 +0100
        Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 14:00 +0100
          Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 15:20 +0100
            Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 19:30 +0100
              Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 22:00 +0100
                Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-27 18:40 +0100
          Re: Package for development of out-of-tree kernel modules written  in Rust Ben Hutchings <ben@decadent.org.uk> - 2025-02-26 19:20 +0100
            Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 19:30 +0100
              Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 20:10 +0100
                Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 20:20 +0100
                  Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-27 18:40 +0100
                Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-02 23:00 +0200
                  Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-02 23:30 +0200
                    Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-02 23:40 +0200
                      Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-03 00:50 +0200
                        Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-03 16:50 +0200
                          Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-03 19:30 +0200
                            Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-03 21:00 +0200
                              Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-03 23:30 +0200
                                Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-03 23:40 +0200
                                  Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-06 23:40 +0200
                                    Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-12 18:50 +0200
                                      Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-13 13:40 +0200
                                        Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-13 17:40 +0200
                                          Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-13 18:40 +0200
                                            Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-13 20:30 +0200
                                    Re: Package for development of out-of-tree kernel modules written  in Rust Ben Hutchings <ben@decadent.org.uk> - 2025-04-16 17:40 +0200
                                      Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-05-03 17:10 +0200
                                Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-04 11:20 +0200
                                  Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-06 23:40 +0200
            Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 19:40 +0100
        Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 14:40 +0100
        Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-02-26 14:40 +0100

Page 1 of 2  [1] 2  Next page →

#86145 — Package for development of out-of-tree kernel modules written in Rust

Hi kernel team!


I know this is early to say the least, but I would like to ask your 
opinion on the naming of a package that could eventually end up in the 
official Debian kernel packaging.

As is the case for C, building out-of-tree kernel modules written in 
Rust [1] requires some extra files to be installed alongside the kernel. 
For C modules this is covered by linux-headers and dependencies. For 
Rust, one needs to have installed the *.rmeta and *.so files which are 
generated in the rust/ directory during the build. The first of these 
contain metadata like the version of rustc used for the build, 
information on exported types/items/etc., bindings and so on [2][3]. 
They do not contain compiled code but are ultimately dependent (among 
other things such as the compiler) on the .config used to build them, so 
they are arch- and flavor-specific. The only *.so file generated at this 
time is a proc macro, and that, to my understanding, is a regular shared 
library.

Needless to say, Rust must be enabled in the kernel for these files to 
be generated, meaning the Debian kernel cannot currently support this. 
However, there is at least one fork of the Debian kernel being built 
with Rust enabled at present, namely, the Asahi kernel which we are 
maintaining in the Bananas Team [4] (which needs Rust for the Apple AGX 
GPU driver), so I started experimenting with the idea of having a 
package to provide these files. Following the scheme of having a 
metapackage + an actual versioned package I added two packages, 
linux-librust@source_suffix@@localversion@-dev [5] and 
linux-librust-@abiname@ [6], the first of which has the second as a 
dependency, while the second contains the actual files and links needed 
to build out-of-tree Rust modules. I tested it with [1] and it worked 
(modulo a small change needed to build [1] outside of mainline). You can 
find a draft at [7].

I would like to include the new linux-librust-* packages in the next 
version of our fork (6.13), but first I would like to ask your opinion 
on the naming I chose, whether you have suggestions (beyond the naming 
too!) and so on. If (when? ;-)) Rust is enabled in the Debian kernel, it 
would be nice to have a package like this to go with linux-headers, so I 
thought I could as well start this conversation to see if I can work on 
something that can eventually end up in src:linux.


One disclaimer: Miguel Ojeda (whom I cc'ed in case something interesting 
comes out of this discussion) told me he wouldn't recommend people to do 
out-of-tree Rust development e.g. because the kernel crate (which lives 
in rust/kernel) may need to be rebuilt to enable or accommodate new 
abstractions. I use this recommendation to clarify that general 
development is not what a linux-librust package aims to enable. The 
problem it tries to solve is "how do I build out-of-tree kernel modules 
written in Rust that work with the kernel installed by my distribution?" 
(this is why it's packaged from the same source!) If your distribution 
does not provide the abstractions you need then your distribution's 
kernel is not good enough for your use-case and you need to rebuild the 
kernel from source, in which case you don't need a linux-librust package 
(you already have the files you need). On the other hand, if your 
distribution does not provide those files, you will not be able to build 
such modules even if your distribution's kernel is good enough for you.


Cheers!


P.S.: Also cc'ing waldi personally since he recently expressed interest 
in enabling Rust in the Debian kernel, and the Rust Team in case someone 
is interested.



[1] https://github.com/Rust-for-Linux/rust-out-of-tree-module
[2] 
https://rustc-dev-guide.rust-lang.org/backend/libs-and-metadata.html#rmeta
[3] 
https://rustc-dev-guide.rust-lang.org/backend/libs-and-metadata.html#metadata
[4] https://salsa.debian.org/bananas-team/wip/linux-asahi
[5] For us this would be linux-librust-asahi-dev, since we renamed our 
source as linux-asahi. For src:linux this would be linux-librust-dev. 
I've been consistent with metapackages such as 
linux-headers@source_suffix@@localversion@ and 
linux-image@source_suffix@@localversion@-dbg and kept @source_suffix@ in 
the package's name.
[6] For us this is linux-librust-$version-asahi, where "asahi" here is 
the flavour name (src:linux-asahi contains an additional asahi flavour 
to enable the configs needed for apple silicon and make it clear to 
users they have to install the -asahi packages instead of the -arm64 
ones). For src:linux this would be linux-librust-$version-amd64, -arm64, 
-arm64-16k, etc.
[7] 
https://salsa.debian.org/bananas-team/wip/linux-asahi/-/commit/7a3873463600bc85781e4683a38d6e510c154937

[toc] | [next] | [standalone]

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

On Wed, Feb 26, 2025 at 01:27:00AM +0100, NoisyCoil wrote:
> Needless to say, Rust must be enabled in the kernel for these files to be
> generated, meaning the Debian kernel cannot currently support this. However,
> there is at least one fork of the Debian kernel being built with Rust
> enabled at present, namely, the Asahi kernel which we are maintaining in the
> Bananas Team [4] (which needs Rust for the Apple AGX GPU driver), so I
> started experimenting with the idea of having a package to provide these
> files. Following the scheme of having a metapackage + an actual versioned
> package I added two packages, linux-librust@source_suffix@@localversion@-dev
> [5] and linux-librust-@abiname@ [6], the first of which has the second as a
> dependency, while the second contains the actual files and links needed to
> build out-of-tree Rust modules. I tested it with [1] and it worked (modulo a
> small change needed to build [1] outside of mainline). You can find a draft
> at [7].

I completely miss the reason why this can't be part of linux-headers and
just be used the same way.

Because those have the same limitations, I would oppose additional
packages just because.

Bastian

-- 
You!  What PLANET is this!
		-- McCoy, "The City on the Edge of Forever", stardate 3134.0

[toc] | [prev] | [next] | [standalone]

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

On 26/02/25 12:29, Bastian Blank wrote:
> I completely miss the reason why this can't be part of linux-headers and
> just be used the same way.

Yeah, I should have explained my reasoning in my previous email.

The metapackage is added so users can choose whether to install the Rust 
bits or not. If you think the user should not have this choice (I don't 
disagree) then the metapackage is not needed. I'm not opposed to not 
having the metapackage.

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 installed under /usr/lib 
instead of /usr/src. This is what's currently being done for the kbuild 
files.

So one alternative could be forgetting about the metapackage, only add a 
new linux-librust-@abiname@@localversion@, and make 
linux-headers-@abiname@@localversion@ depend on 
linux-librust-@abiname@@localversion@ so that's pulled in automatically 
with the headers (like kbuild is). Unless you are fine with 
linux-headers-@abiname@@localversion@ also installing binary files, in 
which case one can just add the Rust bits there. But I still think the 
Rust bits should be installed in /usr/lib [1] instead of /usr/src.


[1] In the draft I'm using 
/usr/lib/linux-librust-@abiname@@localversion@ as installation path.

[toc] | [prev] | [next] | [standalone]

#86154

On Wed, Feb 26, 2025 at 1:13 PM NoisyCoil <noisycoil@disroot.org> 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 installed under /usr/lib
> instead of /usr/src. This is what's currently being done for the kbuild
> files.

Yeah, there are different viewpoints.

The `.rmeta` are binary, in that they cannot be easily read at all,
but on the other hand they are not fully build object files either.
They are acting here like C headers, i.e. containing the same sort of
information from other TUs/dependencies, so in that sense it makes
sense for them to be there.

The `.so` is definitely a built binary, but it is also "like a header"
in the sense that it contains macros that in the C world would have
been in a header.

So it depends on whether the important "part" is 1) how they are
"encoded", 2) whether they are "generated artifacts" or not, 3)
whether splitting things into more packages is better or worse (for
end users, for maintenance...).

For instance, if the `.rmeta` files were generated text files that you
could inspect with a text editor, would you put them in the same or a
separate package? Do you have packages for other Kbuild artifacts that
are required during the build, whether they are text or binary?

I am clueless about distribution details, but I hope that helps somehow...

By the way, it is great to see this kind of discussion -- when I was
writing the step to avoid cleaning those files in the kernel build
system, I wondered where distributions would end up putting them.

Ah, and by the way, there will likely be way more `.rmeta`s and `.so`s
generated (and where they get placed will change) in the future, since
the system will change, so please keep that in mind (e.g. perhaps try
to avoid hardcoding details and/or overfitting on the current setup).

Thanks for the Cc!

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On 26/02/25 13:40, Miguel Ojeda wrote:
> Ah, and by the way, there will likely be way more `.rmeta`s and `.so`s
> generated (and where they get placed will change) in the future, since
> the system will change, so please keep that in mind (e.g. perhaps try
> to avoid hardcoding details and/or overfitting on the current setup).

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 subsystems accept Rust they could be located 
kind of anywhere in the build directory? If this is the case, then I 
think hardcoding can hardly be avoided. One will just have to change the 
hardcoded paths as needed (not ideal, but oh, well; also, absolutely not 
unheard of :-)). I say this mostly because of the *.so files: assuming 
that all *.rmeta files must be installed probably is a good enough 
assumption, but the same is not true for *.so files.

On the other hand, one could maybe use something like `objdump -T 
whatever.so | grep rustc_proc_macro_decls` to discover if a .so file is 
a rust proc macro?

[toc] | [prev] | [next] | [standalone]

#86162

On Wed, Feb 26, 2025 at 3:15 PM NoisyCoil <noisycoil@disroot.org> 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 subsystems accept Rust they could be located
> kind of anywhere in the build directory? If this is the case, then I

Unknown yet -- my current plan is to propose to generate them all in a
single place (which may be different than their current place) for
simplicity. But if people disagree, I may have to place them all over
the tree.

> think hardcoding can hardly be avoided. One will just have to change the
> hardcoded paths as needed (not ideal, but oh, well; also, absolutely not
> unheard of :-)). I say this mostly because of the *.so files: assuming
> that all *.rmeta files must be installed probably is a good enough
> assumption, but the same is not true for *.so files.

If a single place is better for you, that is another argument that I
can use to push for the thing I mentioned above, so I wouldn't mind to
hear that! :)

> On the other hand, one could maybe use something like `objdump -T
> whatever.so | grep rustc_proc_macro_decls` to discover if a .so file is
> a rust proc macro?

In the case where we are everywhere, I guess I could output a file
easily with the paths of all the needed dependencies, if that would
help.

Thanks for the feedback!

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On 26/02/25 19:10, Miguel Ojeda wrote:
> On Wed, Feb 26, 2025 at 3:15 PM NoisyCoil<noisycoil@disroot.org> 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 subsystems accept Rust they could be located
>> kind of anywhere in the build directory? If this is the case, then I
> Unknown yet -- my current plan is to propose to generate them all in a
> single place (which may be different than their current place) for
> simplicity. But if people disagree, I may have to place them all over
> the tree.
> 
>> think hardcoding can hardly be avoided. One will just have to change the
>> hardcoded paths as needed (not ideal, but oh, well; also, absolutely not
>> unheard of :-)). I say this mostly because of the *.so files: assuming
>> that all *.rmeta files must be installed probably is a good enough
>> assumption, but the same is not true for *.so files.
> If a single place is better for you, that is another argument that I
> can use to push for the thing I mentioned above, so I wouldn't mind to
> hear that! 🙂

My personal opinion (which tbf doesn't matter a lot since I won't be the 
one dealing with this in the long run) is if there is no strong reason 
for placing them at specific but seemingly random places, picking a 
single place would be best. A few reasons I can think of:

1. it makes them more discoverable

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 future)

3. if they are scattered all over the tree the package that ships them 
will be a large tree of directories each mostly containing a single rust 
artifact, which is quite ugly imo.

>> On the other hand, one could maybe use something like `objdump -T
>> whatever.so | grep rustc_proc_macro_decls` to discover if a .so file is
>> a rust proc macro?
> In the case where we are everywhere, I guess I could output a file
> easily with the paths of all the needed dependencies, if that would
> help.

If they cannot be put in a single place then, yeah, properly documenting 
their existence will make life easier for packagers. A config-dependent 
file $file generated at build time that one can just `cat $file | cpio 
-pd $DIR` would be enough. Again, this is not so much for .rmeta files, 
those are specific enough to Rust that one can just pull them all in 
(without solving issue 3. above though), but for other stuff like proc 
macro shared libraries which require deeper inspection than looking at 
file names.

> Thanks for the feedback!

Thank you for taking the time to answer!

> Cheers,
> Miguel
> 

[toc] | [prev] | [next] | [standalone]

#86183

On Wed, Feb 26, 2025 at 9:58 PM NoisyCoil <noisycoil@disroot.org> 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 future)

It will definitely be in the future! i.e. the set of `.rmeta`s that
get generated will depend on the kernel config, since we will be
splitting the `kernel` crate.

> 3. if they are scattered all over the tree the package that ships them
> will be a large tree of directories each mostly containing a single rust
> artifact, which is quite ugly imo.

Yeah, it would likely look like that (it is not too ugly for
developers, because they will see other generated files, but yeah).

Thanks for all these points and thinking about this!

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2025-02-26 at 13:40 +0100, Miguel Ojeda wrote:
> On Wed, Feb 26, 2025 at 1:13 PM NoisyCoil <noisycoil@disroot.org> 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 installed under /usr/lib
> > instead of /usr/src. This is what's currently being done for the kbuild
> > files.
> 
> Yeah, there are different viewpoints.
> 
> The `.rmeta` are binary, in that they cannot be easily read at all,
> but on the other hand they are not fully build object files either.
> They are acting here like C headers, i.e. containing the same sort of
> information from other TUs/dependencies, so in that sense it makes
> sense for them to be there.
> 
> The `.so` is definitely a built binary, but it is also "like a header"
> in the sense that it contains macros that in the C world would have
> been in a header.
[...]

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.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken

[toc] | [prev] | [next] | [standalone]

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

Hi Ben,

On 26/02/25 19:11, 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.
> 
> Ben.

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 about it). The first example that 
comes to my mind is the firmware abstractions, which are already in 
stable. So it can't go in linux-kbuild, and if it can't go in 
linux-headers either then it needs a new package.

[toc] | [prev] | [next] | [standalone]

#86165

On Wed, Feb 26, 2025 at 7:24 PM NoisyCoil <noisycoil@disroot.org> 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 about it). The first example that
> comes to my mind is the firmware abstractions, which are already in
> stable. So it can't go in linux-kbuild, and if it can't go in
> linux-headers either then it needs a new package.

I was referring to the `.so`, not the `.rmeta`s, i.e. I thought Ben
was referring to the last paragraph quoted.

The `.rmeta`s definitely depend on the kernel config (and always
will). The `.so` do not get the config passed right now, but we may
end up passing it if we need it. So I would just assume they do.

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On 26/02/25 19:47, Miguel Ojeda wrote:
> On Wed, Feb 26, 2025 at 7:24 PM NoisyCoil<noisycoil@disroot.org> 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 about it). The first example that
>> comes to my mind is the firmware abstractions, which are already in
>> stable. So it can't go in linux-kbuild, and if it can't go in
>> linux-headers either then it needs a new package.
> I was referring to the `.so`, not the `.rmeta`s, i.e. I thought Ben
> was referring to the last paragraph quoted.
> 
> The `.rmeta`s definitely depend on the kernel config (and always
> will). The `.so` do not get the config passed right now, but we may
> end up passing it if we need it. So I would just assume they do.


Ah, I assumed he was talking about both. Ben, do I understand correctly 
that the .so files shouldn't go in linux-headers because you want to use 
*linux-headers* for cross-compiling, meaning everything in linux-headers 
should be usable by the build arch instead of target arch? If this is 
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 checks are performed on the compiler, are they 
only version checks?

> Cheers,
> Miguel

[toc] | [prev] | [next] | [standalone]

#86182

On Wed, Feb 26, 2025 at 8:12 PM NoisyCoil <noisycoil@disroot.org> 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 checks are performed on the compiler, are they
> only version checks?

A single `rustc` can target all targets, like Clang, and unlike GCC.
However, the `.rmeta`s are tied to a single target and compiler and
`rustc` complains otherwise. It will also check some flags like target
modifiers for compatibility too.

I hope that helps!

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On Wed, Feb 26, 2025 at 07:47:39PM +0100, Miguel Ojeda wrote:
> I was referring to the `.so`, not the `.rmeta`s, i.e. I thought Ben
> was referring to the last paragraph quoted.

The .so are for the build architecture:
| debian/build/build_arm64_none_cloud-arm64/rust/libmacros.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0f3c61636b65abb0a499c45e78fb0edf48c82380, with debug_info, not stripped

This means they need to go into linux-kbuild and can not use any config.

Bastian

-- 
Conquest is easy. Control is not.
		-- Kirk, "Mirror, Mirror", stardate unknown

[toc] | [prev] | [next] | [standalone]

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

On Wed, Apr 02, 2025 at 10:38:04PM +0200, Bastian Blank wrote:
> On Wed, Feb 26, 2025 at 07:47:39PM +0100, Miguel Ojeda wrote:
> > I was referring to the `.so`, not the `.rmeta`s, i.e. I thought Ben
> > was referring to the last paragraph quoted.
> The .so are for the build architecture:
> This means they need to go into linux-kbuild and can not use any config.

I don't see any reference to libmacros.so in anything apart the build of
rust/kernel.o.  Is this actually used for module build at all and where?

Bastian

-- 
Schshschshchsch.
		-- The Gorn, "Arena", stardate 3046.2

[toc] | [prev] | [next] | [standalone]

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

On 02/04/25 23:10, Bastian Blank wrote:
> On Wed, Apr 02, 2025 at 10:38:04PM +0200, Bastian Blank wrote:
>> On Wed, Feb 26, 2025 at 07:47:39PM +0100, Miguel Ojeda wrote:
>>> I was referring to the `.so`, not the `.rmeta`s, i.e. I thought Ben
>>> was referring to the last paragraph quoted.
>> The .so are for the build architecture:
>> This means they need to go into linux-kbuild and can not use any config.
> I don't see any reference to libmacros.so in anything apart the build of
> rust/kernel.o.  Is this actually used for module build at all and where?

Re-looping in Miguel. I am in fact able to build the reference 
out-of-tree kernel module without libmacros.so. However, I think this 
depends on whether the specific module being built uses the proc macros 
defined in the macros crate?

[toc] | [prev] | [next] | [standalone]

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

On 02/04/25 23:33, NoisyCoil wrote:
> I am in fact able to build the reference out-of-tree kernel module 
> without libmacros.so.

I take that back, I had deleted libmacros.so from the wrong kernel 
package version. Not only one of the proc macros defined in the macros 
crate is module!(), which is used to declare kernel modules, but without 
libmacros.so the kernel crate is not even found:

error[E0463]: can't find crate for `kernel`
  --> /home/noisycoil/Tmp/rust-out-of-tree-module/rust_out_of_tree.rs:5:5
   |
5 | use kernel::prelude::*;
   |     ^^^^^^ can't find crate

[toc] | [prev] | [next] | [standalone]

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

On Thu, Apr 03, 2025 at 12:33:44AM +0200, NoisyCoil wrote:
> On 02/04/25 23:33, NoisyCoil wrote:
> > I am in fact able to build the reference out-of-tree kernel module
> > without libmacros.so.
> 
> I take that back, I had deleted libmacros.so from the wrong kernel package
> version. Not only one of the proc macros defined in the macros crate is
> module!(), which is used to declare kernel modules, but without libmacros.so
> the kernel crate is not even found:
> 
> error[E0463]: can't find crate for `kernel`
>  --> /home/noisycoil/Tmp/rust-out-of-tree-module/rust_out_of_tree.rs:5:5
>   |
> 5 | use kernel::prelude::*;
>   |     ^^^^^^ can't find crate

Please reference the bug report for this.  Removing a file needs to
produce a file not found error if it is required.

But this means this library needs to be shipped in linux-kbuild and
properly referenced in the build.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
		-- Kirk, "Elaan of Troyius", stardate 4372.5

[toc] | [prev] | [next] | [standalone]

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

On 03/04/25 16:28, Bastian Blank wrote:
> Please reference the bug report for this.  Removing a file needs to
> produce a file not found error if it is required.

What bug report? Is this a suggestion to file one against the upstream 
kernel?

> But this means this library needs to be shipped in linux-kbuild and
> properly referenced in the build.

Miguel said they are unwilling to commit to macros being 
config-independent, so it can't go in linux-kbuild as-is. To be clear, 
are you suggesting that it be made config-independent so it can be built 
in the package for the build architecture (in a cross-compilation 
scenario), and then used for arbitrary target architectures, hence why 
it must be config-independent?

Related to this, I have a question for Miguel: assuming that macros can 
be made config-independent, can one then use the libmacros.so built with 
some kernel for building modules for another kernel (let's say same 
version and either a different config or a different architecture)? Or 
libmacros.so is specific to the build?

[toc] | [prev] | [next] | [standalone]

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

On Thu, Apr 03, 2025 at 07:23:56PM +0200, NoisyCoil wrote:
> On 03/04/25 16:28, Bastian Blank wrote:
> > Please reference the bug report for this.  Removing a file needs to
> > produce a file not found error if it is required.
> What bug report? Is this a suggestion to file one against the upstream
> kernel?

I would assume it's rustc that's broken.  It gives a diagnostic that is
not at all related to the thing you claimed to have removed for testing.

> > But this means this library needs to be shipped in linux-kbuild and
> > properly referenced in the build.
> Miguel said they are unwilling to commit to macros being config-independent,
> so it can't go in linux-kbuild as-is.

What the heck is this good for, where config dependency would be useful?

>                                       To be clear, are you suggesting that
> it be made config-independent so it can be built in the package for the
> build architecture (in a cross-compilation scenario), and then used for
> arbitrary target architectures, hence why it must be config-independent?

It's the basic setup of the Debian Linux package.  linux-kbuild is for
the build arch, aka the system the build runs on; linux-headers-* is for
the host arch, aka the system the kernel is built for.

So, either "macros" is static and unchanging, then we can just build it
and don't care.  Or it is dynamic, then it needs to be built next to the
external module and not be shipped at all.

Bastian

-- 
A father doesn't destroy his children.
		-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
		   stardate 3468.1.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web