Re: [TECH TOPIC] Rust for Linux

[Linus Walleij <linus.walleij@linaro.org>]

On Wed, Jul 21, 2021 at 3:42 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> [Wedson]
> > Preventing functions from being called, when those functions are
> > scattered all over the place (sysfs, etc) may be hard.  Preventing
> > access to a resource seems much more tractable.  That being said,
> > preventing access to the I/O resource in particular seems a bit odd to
> > me.  It's really the whole device that's gone after it has been
> > removed.  So maybe the whole device (for some reasonable definition of
> > "whole device") could get revoked?
>
> I agree that we should view this from a resource point of view, or
> perhaps an object point of view, instead of looking at individual
> functions. A GPIO driver creates GPIO controllers, which are objects
> that expose an API to consumers. In most cases, it's the whole API that
> shouldn't be called after .remove(), not individual functions (there are
> a few exceptions, for instead the .release() file operation for objects
> exposed through userspace as a cdev may need to reach the object). What
> I'd like to see is the subsystem blocking this, instead of having
> individual drivers tasked with correctly handling API calls from
> consumers after .remove(). The correctness of the latter may be less
> difficult to achieve and even guarantee with rust, but that's solving a
> problem that shouldn't exist in the first place.

We have something like this for GPIO but it is coded by a notoriously
crappy programmer (me) in C, so there are some bugs in it pointed
out by Miguel.
https://lore.kernel.org/ksummit/CACRpkdasOaNgBAZVx5qpKJdU7h41jHDG2jWi2+pi9a1JBh7RTQ@mail.gmail.com/

Yours,
Linus Walleij