On Monday, September 26, 2011, Gabriel Michael Black wrote: > That is my intention. I don't think it's a good idea to wait until SE and > FS are completely integrated before committing any code. There are going to > be a lot of changes involved, and I don't want 100 changes sitting in a > queue that I have to keep up to date, forget what the patches are for, etc.
Don't misunderstand me, I'm not saying you shouldn't commit intermediate stages as you go through this process. Obviously you wouldn't want to commit arbitrary intermediate stages though, but only ones that represent a solid step forward and aren't disruptive to everyone else, and I don't think this one fits. > As far as compiling in the code selective, I have my doubts that that's a > good idea. I'm 100% positive that it's a necessary idea. As I said, certainly when we reach that nirvana where you can compile in all the ISAs and all the Ruby protocols into the same binary, we're not going to want to require everyone to always build everything. Unless you disagree with that statement, then we are going to need a good way to control what objects get built and which ones don't, and this seems like a good point to start worrying about it. In fact we already do it with CPU models, so it's not even breaking new ground, though if you say that we need a better mechanism than what we use for CPU models, I won't argue. > It introduces a lot of variability as far as what environment the code gets > built in The whole point of modularity is that not only can you plug in new objects but you can pull out the ones you don't need. If we can't build and run a simulation when you've compiled and linked in only the SimObjects needed to run that simulation (no more, no less), than we're pretty lame, IMO. > , and waiting an extra 30 seconds or less for all the devices to build on a > decent machine is not that big a deal. If you change something unrelated and > do an incremental build, you shouldn't (note I didn't say won't) end up > rebuilding any of those files anyways. > I think you are terribly spoiled ;-). Seriously, I just spent the last weekend installing vmware player on my lenovo x120e (dual-core 1.6 GHz Bobcat) since I was going to be doing some traveling and wanted to be able to do some minor development on the plane. Obviously this is not a development workhorse, but it took well over 10 minutes to compile gem5.debug X86_SE from scratch even after I took O3CPU out of the CPU_MODELS list (since I wasn't going to be using it). And I ran into some platform problems that required me to do some searching across my patch queue to see what the problem was, so I had to rebuild most of the simulator multiple times. (And as you say, the fact that scons is not perfect at not rebuilding things that don't need it, or worse yet not perfect at rebuilding things that do need it, makes this even worse.) I don't think the appropriate answer is to say I should buy a laptop that weighs twice as much and has half the battery life just to make our SConscripts simpler. And even if you don't care about me personally, I bet there are a lot of students out there using gem5 who have to compile on the old PC in the computer lab or something like that. Particularly notice the amount of traffic on gem5-users from outside the US; I'm sure some of those people have very nice equipment, but I'd wager that a lot of them don't. Maybe some of them would consider a dual-core Bobcat an upgrade, I don't know. Anyway, enough ranting... bottom line is that I really don't want to see us compile all devices in unconditionally by default in SE mode. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
