Here's an approach that seems fair to me. I commit this and get devices building in SE mode, and you can add a thing that makes building them optional. Then we both get what we want in the end, and we both only spend time on what we think is important. I don't want to spend time implementing something to make it building devices optional because I don't think it's useful, but I also don't want to take the same amount of time to debate it to death.
Gabe On 09/28/11 00:57, Steve Reinhardt wrote: > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
