@John3909: Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909: > > It makes no sense to discuss that in detail here, since you obviously have > no idea on rapid prototyping controllers. (I can give you a private lesson > if you like.) > On the contrary, perhaps you should explain the use case so everyone here > can understand what it is you cannot do with RemoteProc/RPMSG. Give some > examples of how you do this with libpruio. I just don’t understand the need > for communications with Linux in a tight control loop, but I’m hoping you > can enlighten us on the issue ... > I think Suman did already know what libpruio (and many other high performance PRU projects) need. But here's a private lesson for you: There is no "need for communications with Linux in a tight control loop". We need direct memory access between PRU and ARM CPU. No Linux inbetween. We need to bypass all that vring and RPMsg magic. We gain for speed and small memory footprints. We want to save resources for future extensions and we don't want to spend resources for features that we neither need nor want.
> ... and hopefully move this discussion forward. > To get this discussion forward, we have to move backwards. Neither Suman nor myself want this. So the best way to solve the conflict is, that we get both of our concepts optional. The user should decide if he wants to drive a Jaguar or a Bentley. Since the Bentley has an open trunk where any agressor can easy hide a big bomp, it is a MUST-HAVE to get it out of the mainstream. Remeber, PRUSS can access *ALL* memory. A PRU virus can even override kernel space memory or manipulate kernel drivers. All the safety strategies you explained to William are pointless when a PRU virus overrides your instructions. With network access, a small loader on the PRU could exchange the complete system, auto-started by remoteproc at boot time. And all that vring and RPMsg magic make it even more easy to develop such a malware. Currently, remoteproc is some kind of VCE (virus construction environment), inbuild in the kernel source. I wonder how you can speak about safety and support such a concept at the same time. If you're not just declaiming phrases you learned at highschool, if you have a brain of your own and you're using it, if you really were interested in security, you would second my proposal to make remoteproc optional, and remove it from mainstream. Think of this discussion as a cooperative one were everyone should > ultimately benefit. > Fine that we are at one with this, and you are also ready for corporate development, now. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ebf4bf3f-b545-4efe-9af8-0cb07833217a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
