Re: [PATCH 1/2] remoteproc: Add userspace char device driver

From: rishabhb
Date: Tue Mar 31 2020 - 13:38:31 EST


On 2020-03-31 09:47, Mathieu Poirier wrote:
On Mon, 30 Mar 2020 at 16:45, Bjorn Andersson
<bjorn.andersson@xxxxxxxxxx> wrote:

On Mon 30 Mar 15:12 PDT 2020, Mathieu Poirier wrote:
[..]
> > + struct rproc *rproc;
> > +
> > + rproc = container_of(inode->i_cdev, struct rproc, char_dev);
> > + if (!rproc)
> > + return -EINVAL;
> > +
> > + rproc_shutdown(rproc);
>
> The scenario I see here is that a userspace program will call
> open(/dev/rproc_xyz, SOME_OPTION) when it is launched. The file stays open
> until either the application shuts down, in which case it calls close() or it
> crashes. In that case the system will automatically close all file descriptors
> that were open by the application, which will also call rproc_shutdown().
>
> To me the same functionality can be achieved with the current functionality
> provided by sysfs.
>
> When the application starts it needs to read
> "/sys/class/remoteproc/remoteprocX/state". If the state is "offline" then
> "start" should be written to "/sys/.../state". If the state is "running" the
> application just crashed and got restarted. In which case it needs to stop the
> remote processor and start it again.
>

A case when this would be useful is the Qualcomm modem, which relies on
disk access through a "remote file system service" [1].

Today we register the service (a few layers ontop of rpmsg/GLINK) then
find the modem remoteproc and write "start" into the state sysfs file.

When we get a signal for termination we write "stop" into state to stop
the remoteproc before exiting.

There is however no way for us to indicate to the modem that rmtfs just
died, e.g. a kill -9 on the process will result in the modem continue
and the next IO request will fail which in most cases will be fatal.
I have this scenario written down in the cover letter for this patchset
"[PATCH 0/2] Add character device interface to remoteproc"
I'll add it to the commit text as well.

The modem will crash when attempting an IO while rmtfs is down?


So instead having rmtfs holding /dev/rproc_foo open would upon its
termination cause the modem to be stopped automatically, and as the
system respawns rmtfs the modem would be started anew and the two sides
would be synced up again.

I have a better idea of what is going on now - thanks for writing this up.

I would make this feature a kernel configurable option as some people
may not want it. I also think having "/dev/remoteprocX" is fine, so
no need to change anything currently visible in sysfs.
Ok. Makes sense.

Mathieu


[1] https://github.com/andersson/rmtfs

Regards,
Bjorn