@Jason Kridner I do not think anyone is asking to remove remoteproc, and replace it with uio_pruss. What we've been asking, at least I have been asking is give us the option.
For example, all those modules listed in the output from my lsmod on a fresh install of the latest Jessie testing image: debian@beaglebone:~/nfs$ uname -r 4.4.12-ti-r31 debian@beaglebone:~/nfs$ cat /etc/dogtag BeagleBoard.org Debian Image 2016-06-19 Anyway all those kernel modules should *NOT* be enabled by default. With exception of perhaps the USB gadget drivers(and nfsd is something I personally loaded ). Personally, I would prefer they were not loaded by default, but I can understand the need. Additionally, those kernel modules should be loaded via a device tree file as in how the original uio_pruss module is loaded. So again. I do not care what you all at TI work on. It's not my place to say one way or another. But please do not force us to endure your developers poor clean up abilities. But I will say, that looking at that mess that is the output of lsmod from a released debian image. You all must have zero pride in your work . . . Harsh ? Maybe overly harsh yes, but think about the message you developers are putting out there with that mess. Also as TJF mentioned. Feel free to create your own little sandbox, and then include the stuff you have finished into the released images. That, would make me happy, as well as many others, I'm sure. It's either that, or I'm forced to clean up your mess. Which I am perfectly capable of doing. But that's not the point. Additionally, I am grateful for the work *EVERYONE* has done for the community. Even the people I'm bitching at right now. Take it as overly critical constructive complaints. If you want. On Sat, Jun 25, 2016 at 11:56 AM, Jason Kridner <[email protected]> wrote: > I will work to enable uio_pruss functionality, and I think that is what > you want, not just getting remoteproc out. > On Sat, Jun 25, 2016 at 10:39 AM TJF <[email protected]> wrote: > >> @John: >> >> ... so what do you want removed? There is nothing left to be removed. >>> >> >> I want removed: >> >> >> pru_rproc 12632 0 >> pruss_intc 7223 1 pru_rproc >> >> Do you remember, that's the main topic in this discussion? >> >> >> I think TJF is confusing throughput with latency. From the BeagleLogic >>> project, they were able to achieve better throughput with RemoteProc, but >>> TJF is able to achieve lower latency with PRUSS_UIO. From what TJF >>> explained, the latency occurs because of 5 parameters that must be pushed >>> onto the stack for each call. >>> >> >> I don't think that I'm confusing anthing here. If BeagleLogic could >> really achieve better throughput with remoteproc, they must have had a >> masive problem in their code before. I cannot imagine how any driver could >> have a positive influence on libpruio thoughput. >> >> And regarding latency, the five parameters are just the start. Then >> kernel code and PRU code adds further latency. (And yet the five parameters >> are much too much for my usecase.) The remoteproc concept isn't made for >> high performance and it doesn't provide any "hack" to pass it by. >> >> >> Yeah, so long as you don’t need security, interrupt handling, virtual >>> peripherals (firmware defined devices), etc, why not use a hack to >>> accomplish your task. I guess there is a reason why Linux doesn’t have a >>> lot of userspace drivers. >>> >> >> I see lots of userspace drivers in the real world. Ie. regarding one-wire >> support I know about four. And the numbers will increase, unless kernel >> development gets closer to user needs. >> >> I need security, a high-level target in my projects. That's why I don't >> like virtual peripherals. That's why I don't want to load my firmware from >> files. (I've seen projects where firmware files from userspace gets linked >> to /lib/firmware and loaded. Or when a project runs from SD card, an >> aggressor can easy put the card in a laptop and override the firmware files >> in kernel space.) >> >> So how does this project provide any additional security? When a user >> stops the libpruio firmware at the wrong point using "unbind", this may >> damage the hardware. >> >> Remember, the PRUSS are a safety risc per se. Old-fashioned thinking >> doesn't match the current situation. Im contrast to an arbitrary peripheral >> subsystem, the PRUSS can access all CPU memory. And the kernel cannot >> protect any memory against PRU access. That's why PRU control from the >> command line will not add any security. Instead it'll increase the risc. >> >> >> >>> This is what I like most about RemotProc/RPMSG, in that you are using >>> the same framework between ARM, PRU, DSP, etc. >>> >> >> If I'd be an RPi3 user, I'd love this too. Since it'd help me to develop >> a PRU emulator, using 1, 2 or 3 of the cores for real time tasks. Sure, >> such a project wouldn't really help the BBB community and it wouldn't be >> good for TIs buisiness. So I wonder why TI managers allow to develop this >> remoteproc thingy in public. >> >> >> Suman, you have done very good work. Please take the criticism as >>> suggestions on how to make RemoteProc/RPMSG better. We understand that you >>> have many other responsibilities at TI and we want to be respectful of your >>> time. Thank you again for all your help. >>> >> >> Good work for whom? Competitors are happy. But high performance PRU >> projects doesn't work any more with TI kernels since kernel 4.x (that's >> nearly two years now). And further corporate development is blocked until >> we find a solution. >> >> I also have many other responsibilities. And here, I try to build a >> bridge, and I try to slow down (or stop) the current process of kernel >> development drifting away from user needs. >> >> BR >> >> >> @Suman >> >> Thank you for your answer. Most of your colleagues just stop answering >> and break the discussion when it comes to the point. I really appreciate >> your effort. >> >> And thank you for the examples. They may help others to get started with >> your framework. At the moment, for me, there is still no reason why I >> should spend time in testing. >> >> >> I don't know if pasm assembler is still a supported tool by TI. >>> >> >> As far as I understand, PRU isn't supported by TI at all yet. But pasm is >> the first tool available, and therefor a lot of projects are based on it. >> You shouldn't ignore it. >> >> /dev/mem is your friend. >>> >> >> I don't like /dev/mem. PRUSS are my friends. >> >> Define mainstream. >>> >> >> By mainstream I mean the system a user gets when he installs an image. >> >> >> It is optional, it is not even enabled by default in omap2plus_defconfig. >>> If one doesn't want to spend time, one can always go back to how they were >>> using it with whatever patches they had before. >>> >> >> Yes, downgrading is an option in any case of conflicts. It's the last >> option. And I think it shouldn't be the standard answer when kernel >> developers learn about user needs. >> >> Your project is not optional. As you can see in Williams post, your >> driver gets installed by default in any TI image. >> >> Please try to imagine: not every user compiles his own kernel. Instead, >> most users download and install a prepared image. And this is how it should >> be (@RCN: thanks for all your efforts). >> >> >> And may I know how would you have done it if you were to redo it from >>> scratch supporting both kernel and userspace? You are only looking at it >>> from userspace angle, and as long as you stick to that, any kernel >>> framework will indeed look like bloat. >>> >> >> User space is what kernel is made for. A kernel without userspace >> applications makes no sense. And when a kernel framework looks bloated from >> userspace angle, it may be bloated. >> >> You may know how I'd have started your project. As I said, I'd first make >> the decision: >> >> 1. do I want to make something completely new, or >> 2. do I want to replace an existing solution? >> >> In first case, I would create an experimental project, far away from >> mainstream. In the later case I'd care about existing code and solutions >> (and I wouldn't go mainstream as well, unless I got the basics working and >> documented with examples on how to migrate). >> >> As far as I understand your project, you made this decision. But you >> didn't leave the mainstream yet (and I don't understand how you could >> enter). >> >> >> The TI kernel is not just about BBB, there are 4 other SoC families and >>> multiple boards where PRU is now supported. And we do have userspace needs >>> as well for Industrial usecases, they will get addressed in the upcoming >>> months. You might very well find a thing or two w.r.t UIO in an upcoming >>> Processor SDK release. >>> >> >> I know that you work for other SoC families as well. I wonder why you >> don't add your project to the Processor SDK as an *insiders' tip* or *special >> offer*. By the way, libpruio is already used in lots of industrial and >> scientific projects today. >> >> >> I understand that it's frustrating that the new framework does not >>> address all your needs at the moment, and this is an active development so >>> I will be continuing to close the gaps during the year. >>> >> >> It isn't frustrating that your framework doesn't adress my needs. I >> wouldn't even care about that. It's frustrating that such a framework is in >> the mainstream kernel (images). And it's frustrating that this could get >> fixed very easy, but hasn't been done yet. >> >> Do whatever you think that'll be helpful for anyone at anytime. But do it >> in a sandbox. Don't block corporate development. Don't steal users >> resources. Don't add further riscs to kernels for boards with PRUSS. >> >> Please work with Jason Kridner for any further issues or concerns... >>> >> >> For Jason Kridner I can only repeat: do everthing possible to get >> remoteproc out of mainstream. It blocks the PRUSS development in BB >> community and endangers the BB project. >> >> 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/CA%2BT6QPn8oKQ5jP-D1fhA%3DF6e6%2BeX1c4rFUfLuVj7ZhBbPoQnnA%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPn8oKQ5jP-D1fhA%3DF6e6%2BeX1c4rFUfLuVj7ZhBbPoQnnA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrQPoa5GLbfWCsSm%2BQbi5qLy_8X8FTAmr2HboE%3D0TtYFA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
