On Tue July 1 2008 14:05:00 John Kasunich wrote: > 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.
Much of the kernel exists to facilitate sharing, true; but udev has a slightly different job: to make hardware automatically work as smoothly as possible. I understand and generally subscribe to your model of EMC as an embedded control application running under Linux, and thus not needing much of the resource management features of Linux. But as you say, EMC uses Linux as a development & UI scaffold, and I think firmware loading might have fitted in in this way. Turns out some details prevented this from working smoothly, but i'd have been happy using it if it hadnt had that path restriction problem... > It would be very bad to send a file to the "printer" port > in the middle of a part run. LOL! > > bfload needs to be extended to have better PCI access (access > > to both PCI Config space and PCI device BARs). > > 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. It's a BIOS problem (I think), not a Mesa problem. There are users out there with motherboards that do not set up the Mesa boards PCI Config space properly. At offset 4 in the Config space there's a 16-bit register called Command, which contains a bunch of single-bit flags to enable and disable different features of the device. Some (older?) BIOSes for some reason set these bits to turn off both memory and I/O access to the device! When they're set this way you can't access any of the BARs at all. You can still access the Config space, and if you turn those bits back on you can access the BARs again. So i want bfload to be able to detect that problem and work around it by fixing up the Command register. > 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 ;-) Sounds like emc2 2.2 is for you! :-P > I have absolutely no intention of changing the > computer that runs my mill to Hardy. And nobody is asking you to. But basically the same reasons that make you not want to upgrade your OS should make you not want to upgrade your machine control software. I'd expect emc2 2.2 to be supported on Dapper et al in bugfix mode for a long time to come, while development moves ahead in other branches, on newer versions of the operating system, dropping support for older distros as they age to unmaintainability. > From what I've seen, most of the gripes with Dapper have been of the > nature of "Dapper doesn't support my wireless card". It also doesnt support libpciaccess ;-) > 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. Ok, this is a good conversation to have. What distros are going to be supported by 2.3? > 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. Only a chore on the older (pre-Gutsy) distros. Maybe we could add a --disable-bfload flag for configure. > > 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? Because it has bad smell. Two different PCI access libraries with overlapping yet incompatible functionality (bus enumeration, device representation etc). It's kind of a hokey setup... I'd rather move to a single pci library, and it helps that it's relatively widely used, and maintained by someone else. It's just cleaner. -- Sebastian Kuzminsky my brothers are protons / my sisters are neurons I stir it twice, it's instant family! -- Gogol Bordello ------------------------------------------------------------------------- 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
