Thanks for this summary... it's helpful to discuss some strategy before we get bogged down in tactics.
As I mentioned before, in general I'm very supportive of this direction, so please keep that in mind as I comment on the specifics :-). On Tuesday, September 27, 2011, Gabe Black wrote: > 1. FULL_SYSTEM is not used for conditional compilation. It's only > considered at runtime, or really at compile time still because it's > constant. But it operates only at the level of C++ and not the > proprocessor. > 2. Make FullSystem a property of the simulation and not a constant. At > this point, _SE and _FS suffixes can go away and we can use one build > for both. It'll have to be the runtime constant and global still. > 2. Make FullSystem a property of an object, probably the system objects > and the decoder, and make whatever needs it check for it there. > 3. Make FullSystem an implicit property which reflects how a system is > configured, not a big switch that's flipped one way or the other. > One obvious problem with this plan is that you have two #2s ;-). I'll call them 2a and 2b. Obviously #1 is the big milestone. 2b also seems like a pretty reasonable one (I think pretty clearly it's a parameter on System only... obviously the decoder can go grab that setting and make a copy of it if it wants, but I don't see the need to expose it specifically as a decoder param, if that's what you're proposing), though a relatively small step compared to 1. I don't see a 2a or 3 being that big a deal though... is there more involved in the transition from 1 to 2a than taking the 'const' off of the FullSystem variable (or isFullSystem or Full_System... still haven't resolved that)? If you've really succeeded at #1, I don't think so. SImilarly I don't see a big transition from 2b to 3... once isFullSystem is a parameter on the System object, you're just talking about a couple of lines of python in the config script to set that parameter based on whether the user gives it a Kernel or a Workload (or whatever the names turn out to be). Not that you can't set whatever milestones for yourself that you want; I'm more confused that you would call out such small steps, and wondering if I missed some effort that would be involved in those. > 1. Make devices optional. If a machine has no devices, then it just > doesn't have any devices. If it does then it does. The devices attach to > a system, and there isn't any dependency the other way, except if > software tries to talk to the devices through the memory system. > In what sense are devices not optional now? Obviously if you run in FS and don't have devices, you won't get very far, but is there anything that prevents you from trying? > 2. Make a workload object which encapsulates what needs to be set up to > get a workload running. A kernel workload would load the kernel into > memory, set up any in memory tables, etc. A process workload would load > the process into memory, set up the process stack, etc. They would be > treated the same by the system object and handle the differences by > themselves. > It seems like Process already does this... is this just a matter of encapsulating kernels and the FS setup in a manner similar to what Process already does? Or are there things that you think need to be changed on the SE side too? > One > thing to keep in mind is that this isn't necessarily going to be a > really tidy transition, but I've been trying and will continue to try to > never break any regressions (or anything else, if I can help it). There > are most likely going to be warts throughout the process, but they'll > get cleaned up eventually. We're changing a fundamental aspect of the > simulator, and realistically it's not going to be quick or hassle free. > Understood... but if you're taking path A and I think there's a path B that is equally effective but less disruptive, I will still speak up... Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
