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
On Sun, 2025-04-06 at 23:21 +0200, Miguel Ojeda wrote:
> 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
On 13/04/25 18:17, Miguel Ojeda wrote:
I am not sure I am following correctly the tests, but are you
referring to rebuilding all the Rust artifacts (and not just the host
ones)?
Yes. Only rebuilding the host ones -- that is, the macros -- did not
work. To recap:
1. If the kernel is compiled
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
On 13/04/25 13:14, Bastian Blank wrote:
So we can only ship rust source in any way and the
kernel module make stuff needs to rebuild anything for the external
modules.
Yep, this seems to work [1]. The two tests I did are:
1. Native build on arm64. Installed the build on amd64, replaced the
Ru
On Sat, Apr 12, 2025 at 06:46:31PM +0200, NoisyCoil wrote:
> So I can confirm that builds in fact do not seem to work either way
> currently, the toolchain must be the exact same, as expected. In particular,
> it seems that the arch/config-(in)dependence of libmacros.so is not the main
> blocker he
Hi Miguel,
Sorry for the delay, I wanted to do some tests before answering.
On 06/04/25 23:21, Miguel Ojeda wrote:
So you want to build a kernel for architecture X in a host of
architecture Y, and then build an out-of-tree module for architecture
X in a host of architecture Z (possibly X)?
T
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
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
On Thu, Apr 03, 2025 at 11:08:08PM +0200, Miguel Ojeda wrote:
> 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?
C macros are
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 o
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 t
On 03/04/25 23:08, Miguel Ojeda wrote:
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?
I think the
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
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
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 lin
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 u
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 mea
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
s
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
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
On 26/02/25 19:10, Miguel Ojeda wrote:
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
On 26/02/25 19:47, Miguel Ojeda wrote:
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
con
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
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
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
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 Wed, 2025-02-26 at 13:40 +0100, Miguel Ojeda wrote:
> 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 differ
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 Wed, Feb 26, 2025 at 01:13:45PM +0100, NoisyCoil wrote:
> Unless you are fine with
> linux-headers-@abiname@@localversion@ also installing binary files, in which
> case one can just add the Rust bits there.
The headers package includes many generated files that can
On 26/02/25 14:22, Bastian Blank wrote:
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.
There is no need to get picky, sorry.
No need to be sorry, this is the kind of feedback I am looking for. If
you confirm
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
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
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
34 matches
Mail list logo
