lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87jzbxmij3.fsf@kernel.org>
Date: Wed, 18 Dec 2024 10:45:20 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Alistair Francis" <alistair23@...il.com>
Cc: "Alistair Francis" <alistair@...stair23.me>,
  <linux-kernel@...r.kernel.org>,  <benno.lossin@...ton.me>,
  <boqun.feng@...il.com>,  <me@...enk.dev>,  <alex.gaynor@...il.com>,
  <gary@...yguo.net>,  <aliceryhl@...gle.com>,  <alistair.francis@....com>,
  <bjorn3_gh@...tonmail.com>,  <tmgross@...ch.edu>,
  <rust-for-linux@...r.kernel.org>,  <ojeda@...nel.org>
Subject: Re: [PATCH v4 00/11] rust: bindings: Auto-generate inline static
 functions

"Alistair Francis" <alistair23@...il.com> writes:

> On Wed, Dec 4, 2024 at 11:14 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>>
>> Hi Alistair,
>>
>> "Alistair Francis" <alistair@...stair23.me> writes:
>> >
>> > This series adds support for bindgen generating wrappers for inline statics and
>> > then converts the existing helper functions to this new method. This doesn't
>> > work for C macros, so we can't reamove all of the helper functions, but we
>> > can remove most.
>>
>> Are you aware of the helper LTO patches by Gary [1]? Can you tell if
>
> I was not, but that's exciting to see
>
>> this series will compose with the LTO patches?
>
> I think it will still work, although it might take some extra effort.
>
> I assume my series isn't going to be accepted though, so I'm not going
> to try and get the LTO series to work on top of it. It's a lot of work
> to rebase this series as every new binding causes a conflict and it
> seems to have stalled

I would assume that it _will_ be merged in some form. Why not? It's just
a matter of getting it reviewed and making sure that it is going to work
with the LTO inlining.

The less boiler plate code we have to write by hand, the better!


Best regards,
Andreas Hindborg




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ