Hi Alan, Federico, On Fri, Aug 17, 2018 at 6:19 AM, Alan Tull <atull@xxxxxxxxxx> wrote: > On Fri, Aug 17, 2018, 2:00 AM Federico Vaga <federico.vaga@xxxxxxx> wrote: >> >> Hi Mortiz, >> >> I'm not 100% into the problem to understand all cases. I'm putting on the >> table the point of view, mainly, of an user. If you say there are problems >> here or there I believe you. At the beginning, you did not say that this >> interface may introduce problems (and I'm interested in those problems >> since I >> implemented one and we are using it), but that you fear that it becomes >> the >> default (usually, being a default is a good thing). >> >> Since you and Alan are working on this for a long time, you can read each >> other mind, but I need a more verbose email to understand ^_^' >> >> Of course the interface must be safe, I totally agree. In order to make me >> understand what are the issues, can you list some of them? Say you have kernel drivers (a network driver in the FPGA, or an I2C controller) for example bound to hardware on a MMIO bus in the the FPGA. You reprogram the FPGA using the debugfs interface, and the drivers don't get unloaded correctly, the driver will try to access the registers and depending on your system / bus either give you bad values or lock up. Now userland locked up your system. Bad. I'm not saying it isn't possible to do this if you're careful, of course you could first unload the drivers using rrmod and it would work just fine. I just feel an interface like this might make it easier to create the wrong design. I've seen plenty of Application notes from vendors where they literally did "cat foo.bin > /dev/fpga" followed by mmap(/dev/mem...). > > > Before we repeat what the doc l posted says, could you look at it and > comment on what I'm not saying there? > > https://lkml.org/lkml/2018/8/15/525 Alan, maybe I didn't express myself well. I'm fine with the debugfs interface as a debug interface, just not for general usage ;-) I think your document is clear on that. Thanks, Moritz
