Sebastian Kuzminsky wrote: > 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 would still argue that udev's job is to make the hardware work as smoothly as possible _in the Linux environment_ and we at least to some extent working _outside_ that environment. The reason the kernel guys don't want to allow arbitrary path support is because they have different goals and priorities than we do. Nothing wrong with that, as long as we recognize it and act accordingly. >>> 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. > OK, that explains why it affects only some systems. >> 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 want new features that will be part of EMC 2.3.x and beyond. I don't see why I should have to update my entire operating system to get them. Sure, someday there will be some killer feature (or killer bug) that forces us to drop support for Dapper in TRUNK. But this doesn't qualify, IMO. >> 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. Updating 1% of the code on my computer (EMC itself) to get new features is a reasonable risk to take. Replacing the entire operating system and every package for those same new features seems a bit much. > 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. > I intend to have both an installed 2.2 and one or more CVS checkouts on my machine. I admit that a regular user won't need or want to do that, but any developer might. If all I'm doing is running parts, I'll probably use the installed version. If I'm doing development, or testing something new that someone else has developed, or simply running a part that _needs_ a new feature, I'll use the newer version RIP. And eventually I'll replace 2.2.x with 2.3.x. For example, this week I need to test low-ppr threading. I've written the basic code on my development box, but I want to actually cut threads to make sure it works. You'd force me to install Hardy (or manually download and install libpciaccess) before I can run CVS code on my machine. > >> 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 ;-) How many users are griping about that? ;-) >> 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? I'd like to see: 1) Official support (including .debs) for Hardy with our RT kernel 2) Official support (including .debs) for Dapper with our RT kernel 3) Official support (.debs optional) for simulator mode on vanilla Hardy with the stock kernel 4) Official support (.debs optional) for simulator mode on vanilla Dapper with the stock kernal 5) Unofficial support (no .debs, but the code works if you compile it) for Breezy with our RT kernel 6) Unofficial support (no .debs, but the code works if you compile it) for BDI-4.51 (includes an RT kernel) 7) Unofficial support for simulator mode on "generic Linux", with the understanding that ./configure is going to fail until people install missing dependencies. I agree that is a conversation we should be having. > > >> 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. You mean "all distros except Hardy". We have not released RT kernels for anything between Dapper and Hardy. Those few intrepid souls who have built RT kernels for Feisty or Gutsy or Fedora or Suse aren't the ones I'm worried about. Our "chain of supported distros" is BDI, Breezy, Dapper, and Hardy. Dropping 3/4 of that chain in one fell swoop is what is giving me heartburn. >>> 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... > Understood. But hokey or not, it still needs to be done for 2.2. Once it is done and works, why not just keep using it? I thought we had talked about extending upci to provide config space access. I realize that might also be hokey, but it avoids a lot of the duplication duplication. > 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. I guess "widely used" depends on your perspective. I have no data to back this up, but I think of our user base as being 10% pre-Dapper, 80% Dapper, and 10% Hardy. I'm sure the Hardy percentage will climb rapidly over the next year, but even in 2009 I bet Hardy will be less than 50%. 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
