On Tue 31 Mar 09:47 PDT 2020, 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. > > The modem will crash when attempting an IO while rmtfs is down? > In certain cases there's nothing else to do. > > > > 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. Sounds reasonable. > I also think having "/dev/remoteprocX" is fine, so > no need to change anything currently visible in sysfs. > I agree, it sure is annoying that remoteproc%d isn't stable, but it's what we have and consistency is important. Regards, Bjorn
