Re: [TECH TOPIC] Rust for Linux

Wedson Almeida Filho
2021-07-21T14:13:16Z

On Wed, Jul 21, 2021 at 03:54:33PM +0200, Linus Walleij wrote:
> 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/

Would you mind sharing details of the bugs Miguel found?

Thanks,
-Wedson