Sebastian Kuzminsky wrote: > On Tue July 1 2008 15:45:57 John Kasunich wrote: >> 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 see your point. > > There's a judgement call here: accumulating cruft to support older > platforms, or abandoning older platforms for a cleaner product.
Exactly - it is a judgment call, and not everyone is going to have the same idea of what is "older". For me, Dapper is not old. For you it is. > > Me, I'm allergic to cruft and I dont mind upgrading to stay in sync with > the rest of the open source community. I tend to stay on the trailing edge where things are more stable. I'm going to move my main day-to-day computer over to Hardy one of these days, but I wouldn't be surprised if that doesn't happen until fall. I just don't see any real benefits - what I have works, why fix it? > And IMO, upci+libpci definately counts as cruft. I can see your point as well - there is definitely duplicate code there. > I guess the board will decide? How does the emc2 project make decisions > like this? Hopefully by consensus. I think we are moving in that direction. >> 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. > > Or disable bfload and everything that depends on it. After someone adds > "configure --disable-bfload"... Now that is cruft. (I guess cruft is in the eye of the beholder.) If we must skip building some part of EMC, we should at least have configure do it automatically - after printing a big warning "the following utility program(s) won't be built because dependency libpicaccess is missing". > I dont want to support older distros. They hold us back. > > Dapper doesnt have firefox 3, or even firefox 2. It's stuck back on gcc > 4.0.3, glibc 2.3.6, gnome 2.12, KDE 3.5.2, and python 2.4. It's still > supported, but development has moved on. First, who cares about firefox on a machine control? Second, what does firefox 2 or 3 provide that firefox 1 doesn't? That last question isn't rhetorical - I have no idea what the answer is. Until the last few weeks I didn't know there was a new firefox coming, then I ran across some hoopla somewhere about FireFox 3. I didn't know (or care) what version of FireFox I am running until I looked just now. As you can tell, I have a really strong reaction to the "everything must be as new as possible" mindset. I hate change for the sake of change. > "The 'portability to every insane system' disease causes insanity > on *all* platforms." -- H. Peter Anvin I'm not arguing for portability to every "insane" system. I'm arguing for _less_ insanity, where insanity is defined as the ever faster race to replace last year's perfectly functional system with a new one that will in turn be replacec next year. >> 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. > > We did talk about that, and I dont think it'd be hokey to do that. > > But in parallel with our conversation, I talked with the libpci folks. > Martin Mares said he'd gladly accept a patch to add BAR access to libpci. > Surely you agree it's best to put the development effort where it will > see the most use/debugging and help the greatest number of people. > Between either merging the libpci code into upci or merging the upci > code into libpci, the choice seems obvious to me. If you look only at new systems, yes. But what about the installed base that doesn't have the newly merged libpci with BAR access? > But then someone on the linux-pci list suggested libpciaccess from X.org, > which already has everything we need. And that seemed an even better > choice to me. > Agreed, if you don't care about breaking old systems. > Hm, how about this? We could switch bfload to libpciaccess, and fork > libpciaccess into our repo, for use on old platforms that dont have it > available "natively". We already carry a pci access library around with > us, might as well make it one that's seen some use and testing by the > community, something that might just be familiar to outsiders peeking in. > THAT is a solution that I can happily live with. My problem is not with libpciaccess itself - I agree that it is the cleanest way to accomplish PCI access. My problem is with the apparent willingness to discard what I consider a very recent distro. Many of the people who are doing retrofits of older machine tools are doing so because the old controls have failed and are no longer economical to repair. We're talking about five or ten or twenty year old controls here. In an industrial application, two years old is just barely long enough to get the bugs worked out and start to trust the thing. >>> 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%. > > I meant the pci access library is widely used. X (and libpciaccess) > must have 1000,000x as many users as emc2 (and upci). Ok, we were talking past each other then. I'm only interested in EMC's users, and upci works for them. If my numbers above are correct, then 90% of EMC users don't have libpciaccess. Therefore it is not "widely used" by our userbase. That said, I must admit that upci will inevitably break when some kernel hacker decides that the PCI APIs have been stable for a year or two and therefore must be changed. libpciaccess has maintainers who are willing to keep running on that treadmill, and for that reason alone, we should use it. But we need to figure out how to use it without killing off Dapper and inconveniencing our Dapper based users. BTW, sorry I missed you this evening on IRC - I had an opportunity to go sailing and I took it. On IRC you mentioned that the Dapper compile farm "slot" hasn't run since April. That is because the Dapper "slot" is a real PC that I haven't been running much lately. (The "slot" terminology is left over from the first compile farm, which was an old Cubix blade system with 8 real slots, each of which contained a 200MHz Pentium single board computer with 128M of RAM. I pulled it from a dumpster several years ago. It served us well for about 2-1/2 years before it went back into the dumpster.) The other farm machines are actually virtual machines running as guests on my main PC. The main PC is running generic Dapper without a RT kernel, and runs 24/7. As mentioned above it will be moved to Hardy someday, but I'm dreading that - especially reinstalling vmware. It isn't particularly hard, but it takes time that I'd rather spend making real progress on something. I should move the realtime Dapper "slot" to a VM so it can run all the time too. It hasn't been much of an issue until very recently, since almost all development was being done on Dapper boxes. So the code was usually tested on Dapper before being committed, and the farm was mostly to check for breakage on other systems. Now that some developers are moving to Hardy, I should be running the Dapper farm more religiously, and I should probably add Hardy to the farm. I'll add that to the to-do list. 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
