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
| ||
|
Message-Id: <20231029.132112.1989077223203124314.fujita.tomonori@gmail.com> Date: Sun, 29 Oct 2023 13:21:12 +0900 (JST) From: FUJITA Tomonori <fujita.tomonori@...il.com> To: benno.lossin@...ton.me Cc: andrew@...n.ch, fujita.tomonori@...il.com, boqun.feng@...il.com, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu, miguel.ojeda.sandonis@...il.com, wedsonaf@...il.com Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers On Sat, 28 Oct 2023 18:45:40 +0000 Benno Lossin <benno.lossin@...ton.me> wrote: > On 28.10.23 20:23, Andrew Lunn wrote: >> On Sat, Oct 28, 2023 at 04:37:53PM +0000, Benno Lossin wrote: >>> On 28.10.23 11:27, FUJITA Tomonori wrote: >>>> On Fri, 27 Oct 2023 21:19:38 +0000 >>>> Benno Lossin <benno.lossin@...ton.me> wrote: >>>>> I did not notice this before, but this means we cannot use the `link` >>>>> function from bindgen, since that takes `&self`. We would need a >>>>> function that takes `*const Self` instead. >>>> >>>> Implementing functions to access to a bitfield looks tricky so we need >>>> to add such feature to bindgen or we add getters to the C side? >>> >>> Indeed, I just opened an issue [1] on the bindgen repo. >>> >>> [1]: https://github.com/rust-lang/rust-bindgen/issues/2674 >> >> Please could you help me understand the consequences here. Are you >> saying the rust toolchain is fatally broken here, it cannot generate >> valid code at the moment? As a result we need to wait for a new >> version of bindgen? > This only affects bitfields, since they require special accessor functions > generated by bindgen, so I would not say that the toolchain is fatally broken. > It also is theoretically possible to manually access the bitfields in a correct > manner, but that is error prone (which is why we use the accessor functions > provided by bindgen). > > In this particular case we have three options: > 1. wait until bindgen provides a raw accessor function that allows to use > only raw pointers. > 2. create some C helper functions for the bitfield access that will be replaced > by the bindgen functions once bindgen has updated. > 3. Since for the `phy_device` bindings, we only ever call functions while holding > the `phy_device.lock` lock (at least I think that this is correct) we might be > able to get away with creating a reference to the object and use the current > accessor functions anyway. > > But for point 3 I will have to consult the others. The current code is fine from Rust perspective because the current code copies phy_driver on stack and makes a reference to the copy, if I undertand correctly. It's not nice to create an 500-bytes object on stack. It turned out that it's not so simple to avoid it.
Powered by blists - more mailing lists