On 09/28/11 00:56, Steve Reinhardt wrote: > 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.
Changing the scripts may or may not be a big deal. Our scripts are not very modular or flexible, so it's hard to say. From 1 to 2a there may not be that much of a change, but it does enable having one build. I was just listing whatever I thought of at the time. > >> 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? If you have to have a platform object, you have at least one device, the platform object, and I think you have to have the interrupt controller to. And then you have to build in the things that those connect to, and the things that they need to compile, and blah blah blah. Nothing about that is very clean. The reason we have little threads of dependence throughout the simulator is that they all seem like harmless little quirks until they get in your way and make everything 10 times harder. > >> 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? A workload is a generalization that subsumes processes, kernels, etc. A process is a specialization of a workload, and so is a kernel. Both involve a lot of goop to set things up, especially on the x86 side with its 15 flavors of BIOS tables in memory. Neither is a subset of the other, but they have a lot in common. > >> 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... Yes, and that's reasonable. Remember, though, that it takes effort just to find the time to write the code, let alone actually writing it or the weeks of debate that inevitably follow. I'm not keen on redoing everything and taking another week or month to get back to where I already am, especially when it's a transitory change. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
