Re: [TECH TOPIC] Rust for Linux

James Bottomley
2021-07-07T11:34:41Z

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Wed, 2021-07-07 at 11:50 +0100, Mark Brown wrote:
> On Tue, Jul 06, 2021 at 10:36:14PM +0200, Linus Walleij wrote:
> > On Tue, Jul 6, 2021 at 10:00 PM Roland Dreier <roland@kernel.org>
> > wrote:
> > > "devres" / devm_xxx was an attempt to deal with this in C, but it
> > > only solves some cases of this and has not received a lot of
> > > adoption (we can argue about the reasons).
> >
> > Really? From my point of view that is adopted all over the map.
> > I add new users all the time and use it as much as I can when
> > writing new drivers.
>
> Yes, it's *super* widely used in most of the kernel. Perhaps there's
> some subsystems that reject it for some reason.
>
> > I think it's a formidable success, people just need to learn to do
> > it more.
>
> There *are* issues with people adopting it too enthusiastically - as
> well as the memory lifetime issues that Laurent mentioned it's easy
> for it to cause problems with interrupt handlers that are left live
> longer than they should be and try to use things that were already
> deallocated.

Fixing this should not be beyond the wit of humankind, though. If we
delayed deallocation to module release, that would fix the interrupt
issue, wouldn't it? Perhaps all devres memory for devices should live
until then anyway and thus be automatically deallocated instead of
needing an explicit free ... the problem with that being compiled in
devices currently optimize away the module refcounting, but that should
be fixable.

James

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]