This message from Przemek didn’t get copied to everyone but I thought he had an interesting prospective to this discussion.
Regards, John > Begin forwarded message: > > From: Przemek Klosowski <przemek.klosow...@gmail.com> > Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly Changed > Date: June 27, 2016 at 8:59:59 AM PDT > To: beagleboard@googlegroups.com > Reply-To: beagleboard@googlegroups.com > > On Mon, Jun 27, 2016 at 3:51 AM, TJF <jeli.freih...@gmail.com> wrote: >> 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. > > This is a valid design pattern and you did very impressive things with > it, but it's not compatible with the basic design of Linux hardware > integration: I don't know of a single mainline kernel driver designed > this way. The whole point of a kernel driver is that it abstracts the > hardware and presents the unified abstraction to the rest > (open/read/write/ioctl/skbuf/etc). Of course this costs performance, > and so the development identifies those bottlenecks and tries to come > up with more abstractions like no-copy networking, etc. > The challenge for those abstractions is to provide speed while still > maintaining security, e.g. by disallowing full control of the entire > physical address space. There have to be address space checks on those > kernel-userspace transitions, and they will use up some cycles; you > can optimize them but can't just not do them. > > It seems to me that you just don't want the Linux machinery to > intervene: your design does feel like a bare metal, tight control > loop, using Linux mostly for setup, program loading and > administration. > > Also, I would be personally obliged to you if you could refrain from > commenting on other people's motivations and abilities, and just keep > focused on the technical points everyone is making. The discussion is > much more productive this way. > > -- > 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 beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGAQBn%2BAgt76ivjMW3h3Yon7hXbEROcU%2BwubWS4YG6%3DJg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/219EBBCF-7CDE-4111-9529-4363CC274843%40gmail.com. For more options, visit https://groups.google.com/d/optout.
