[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: