nathan binkert wrote: >> Hey, quick python simobject question. I'm thinking of creating an >> object file symobject type for various reasons, but I want to make it so >> it can still be instantiated with a string parameter. So in other words, >> I still want to be able to say process.executable = "foo", but then for >> process.executable to be an ObjectFile simobject which constructs itself >> around that string parameter. It all sounds very plausible, but since >> there's some fancy magic going on with the SimObject stuff I thought >> rather than flounder around trying to get it to work I'd just ask what >> the prescribed approach is. Is there a straightforward way to do that? >> > > Why exactly do you want it to be a SimObject? Could it just be a > special parameter type? I actually have some code for special file > parameter types depending on exactly what you're trying to do, it may > be of use to you. All that said, if you do want it to be a SimObject, > but do some special parameter handling for it, I'm pretty sure it > could be done, but I'd have to think about how. My guess is that we'd > have to do some cleaning up of the ParamDesc.convert. Perhaps simply > implementing a convert() function on SimObject and then overriding it > on your special FileType of simObject. In all honesty, I'll admit > that this code is pretty messy and the code is somewhat all over the > place. A first step would probably be to document (maybe in the form > of a sequence diagram or something like that), exactly how SimObjects > are defined and instantiated. The problem with the code right now is > that we're using the same mechanism to do both things (python class > instantiation), so the code is a bit intertwined. I think we could do > a much better job than we have and it would make things less opaque. > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
After a little more digging I'm less convinced I actually need to be able to do this, although I'm not really sure. What I'm trying to do is break up the big #if in the LiveProcess::create function (not LiveProcessParams::create, although that just calls this other one). It's in sim/process.cc. Initially I'd been thinking we had process types for each of the ISAs (we don't) and that if the ObjectFile type was already set up and ready to go those create functions could check what arch, etc., was in use and return the right type of process object. The reason I was looking at that was that I wanted to try to support or at least distinguish 32 bit kernels since according to the mailing list people occasionally try that. We at least need to complain if they do (patch on reviewboard), but I'd like to start building the structure needed to get it to work if not actually get it to work in some limited way. I looked at how we decide what Process to use and how to initialize it, and I found the somewhat unwieldy #if. I want to rework that code to delegate the code in the #if to a virtual function in the Process or System objects, or ISA utility function, or somewhere it can be compartmentalized and not driven by the preprocessor. I want to then follow a similar pattern with System objects so that x86 can choose intelligently whether to use a 32 bit or 64 bit system object and to initialize things correctly accordingly based on the architecture of the kernel object file. Then, assuming it doesn't turn into a big mess, I'd like to combine the Process and System object file loading code through some sort of base class. If that works out (and maybe if it doesn't) then we may be within walking distance from a unified interface to back hypercalls. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
