@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/ec29a542-ce87-470c-ad2d-938cf7f47df4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
