paul_c wrote: > Tried sending to the list, but it bounces... Can't be a&%$ to fix it. > > > Here's some things we want from the firmware loading solution: > > > > 1. Developers and users who compile from source and Run-In-Place > > must have a convenient way to choose which firmware gets sent to > > each board. > > module_param(firmware, charp, 0444); > request_firmware(&fw, firmware, dev);
I tried to find out how this would work. Google found http://lwn.net/Articles/32997/ which is ancient, but it is the only "in plain english" explanation of how request_firmware works that I could find in a quick search. If the current reality is different, please point me to better docs. From that page: In the new scheme, a device driver needing firmware for a particular device makes a call to: int request_firmware(struct firmware **fw, const char *name, struct device *device); Here, name is the name of the relevant device, and device is its device model entry. My first objection: the struct device. We are not writing Linux device drivers, we are writing drivers that make a device available to ONE application that is running in realtime context. Few (none?) of our existing drivers have device model entries. Getting such an entry isn't a huge burden, but it is yet another connection to Linux, and yet another way for changes in the kernel APIs to break our drivers. Paul might argue that we _are_ writing Linux device drivers. I have already stated in this thread why I think we are writing embedded controller code that happens to run on a Linux box. Neither of us is going to convince the other, so I won't even try. Continuing with the description of request_firmware: This call will create a directory with the given name under /sys/class/firmware and populate it with two files called loading and data. A hotplug event is then generated which, presumably, will inspire user space to find some firmware to feed the device. So we need hooks into the hotplug system. More documentation to read, more code in our drivers, more connections to Linux APIs that have little or nothing to do with machine control. (I sure hope nobody is hotplugging machine control components.) The resulting user-space process starts by setting the loading sysfs attribute to a value of one. The actual firmware can then be written to the data file; when the process is complete, the loading file should be set back to zero. Is this user space process already provided by the hotplug system, or do we have to write it? If the latter, how is it any better than bfload, which is already a user space process? At that point, request_firmware() will return to the driver with fw pointing to the actual firmware data. So all these steps have only managed to get the data from disk into kernel space memory. The driver still needs to transfer it from memory to the FPGA. bfload does that directly, so the "load from memory into FPGA" code doesn't have to be in kernel space at all. > > There are basically two ways to do it: > There is only one correct way of doing it. An assertion without the reasoning behind it isn't going to convince anybody. Anybody can assert that their way is the "only one correct way". > > The lack of feature 1 (RIP) really kills this idea. We'd > > have to have people symlink parts of their sandboxes into > > /lib/firmware, and that's probably too gross. This problem > > is an indication that the hostmot2 subsystem is straining > > the emc2 RIP model, but I realize that model is not about > > to change any time soon... > R-I-P is a hangover from the NIST days and contributes much to > many of the poor decisions inflicted on the user. That is easy to say for someone who doesn't do EMC2 development or support. RIP allows us to run the current released version (to investigate problems reported by users), the bugfix branch (to fix those problems and test the fixes) and the CVS trunk (to add new features). I'm open to alternate ways of achieving those goals, but the burden of proving that a new method works is on the one proposing the change. > Dump the cruft and move on. RIP is not cruft until a viable alternative exists. In my view there are fundamental differences between the Linux driver model and what EMC2 needs. Maybe we should discuss this - if my view is in the minority, maybe I need to be convinced to change it. My ideal model for all the realtime parts of EMC (not just drivers) consists of having a minimal amount of interaction with Linux - just enough to tell Linux "I own this device (memory range, I/O ports, etc), keep your bloody hands off". The more Linux APIs we use, the more maintenance we will have to do as those APIs change over the years. The more I think and write on this subject, the more I feel like I'm preaching a 1980s or 1990s programming style in the face of the inexorable march into the 21st century. But it really pains me that such fundamentally simple tasks as talking to hardware have gotten so damned complicated. I just want get things set up, and then have the OS get the hell out of the way. Regards, John Kasunich ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
