Sebastian Kuzminsky wrote: > I've been talking to people and thinking about firmware loading for the > hostmot2 subsystem. This email presents the results of this inquiry > and my plan for the future. The short version is i'll be sticking with > bfload, and using libraries other than upci to supply the missing PCI > access methods. Read below for all the details. >
(snip) Well researched and well written - I need more time to digest everything. But I do have some thoughts: Regarding the udev firmware loading mechanism - for me this has never been very attractive (it has been brought up before). It comes down to a philosophical difference, and perhaps I'm the only one who looks at it this way. I'm not sure if I can put my thoughts into words, but I'm gonna try. The kernel, udev, and "all that stuff" exist to perform one task - to make the hardware installed in a computer available to _all_ of the applications on that computer. There are many layers of abstraction involved - user programs don't access hard disks, they access filesystems, which access block devices, which eventually access disks. The same is true for network protocol stacks, etc. But regardless of the layers involved, the operating system is managing that hardware for the benefit of the _entire_ computer and _all_ of its applications. EMC is different, or at least I think it is. For machine control purposes, I think of the PC as a very powerful and fast embedded controller, with a really nice and convenient development system (called Linux) attached to it. The hardware that EMC is using is dedicated to that machine control task and is NOT shared with the operating system or the rest of the computer. For example, with parport stepper systems we need to make sure that Linux doesn't think there is a printer attached to the port. It would be very bad to send a file to the "printer" port in the middle of a part run. That is why I tend to avoid trying to stuff our code into the Linux device driver model - we are not driving Linux devices. We are driving dedicated machine control hardware - even if that hardware is simply a parallel port. RTAI works outside of (or underneath) Linux, in order to deliver the "embedded controller" performance we want. I think there is nothing wrong (and a lot right) about a driver model that works the same way. I am aware that others probably don't share this philosophy, and am willing to consider arguments against it. There are certainly weaknesses to the "embedded controller" approach, especially when people want to offload the realtime stuff to genuine embedded controllers in external hardware. > > It's sadly awkward to do in-kernel firmware loading from user's home > directories (or any non-standard firmware directory), as needed by our > RIP use case. Thus we cannot use udev, and we're stuck with bfload. > > bfload needs to be extended to have better PCI access (access > to both PCI Config space and PCI device BARs). > upci currently > supports BAR access only. libpci supports Config space access only. > libpciaccess supports both [2]. Can you clarify exactly what config space access is needed for? I recall you telling me very briefly one night on IRC, but I never understood the details, and others here don't have any of that information. The basic bfload task is "load an FPGA configuration", and that _can_ be done using BAR access only. My understanding was that config space access is only needed to implement a workaround for a bug in some number of early production Mesa cards. > I plan to support TRUNK by moving bfload from upci to libpciaccess. > I wont mess with upci, pci_read, or pci_write in TRUNK. libpciaccess > is packaged for Ubuntu starting with Gutsy, but it's not available > for Dapper [3]. Now the problem: > This means TRUNK wont work on Dapper unless the > developer installs libpciaccess by hand. Hardy is here and it's > time to move on. I'm not ready to move on yet ;-) One big difference between machine controls and "typical" computer applications is the much longer life cycles. I am nowhere near ready to consign Dapper to the scrapbin. I _might_ move my main computer to Hardy one of these days. I have absolutely no intention of changing the computer that runs my mill to Hardy. I can think of no reason to do so. From what I've seen, most of the gripes with Dapper have been of the nature of "Dapper doesn't support my wireless card". I realize that there will come a time when we have to move on from Dapper, just as we have moved on from 2.4 kernels, etc. But I don't think we've reached that point yet. TRUNK currently builds not only on Dapper, but on Breezy and on the BDI-4.51. I haven't discussed this specific issue with the board, but I think we had a general consensus that the 2.3.x release series wouldn't have Breezy and BDI support as "must have". But nobody has talked about dropping support for Dapper. I consider Dapper to be the mainstream, with Hardy as something for the early adopters to use. What makes this worse is that the dependency on libpciaccess will make it a chore to compile EMC, even for people who have no mesa card and have no intention of _ever_ using bfload. Making all of EMC depend on an unpackaged library, to support one workaround for a one problem on a small subset of one brand of hardware device, seems a high price to pay. > I plan to support the 2.2 branch by using both upci and libpci > in bfload. I wont mess with upci, pci_read, or pci_write in 2.2. > libpci is available for Ubuntu releases back to Dapper [4]. > If it is possible to do this for 2.2, then why not do the same in trunk? > That's the plan. Object now or forever hold your peace. See above ;-) 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
