Bugzilla – Full Text Bug Listing |
Summary: | It would be useful to have a pre-simulate state (and post) | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Craig Dowell <craigdo> |
Component: | core | Assignee: | Mathieu Lacage <mathieu.lacage> |
Status: | NEW --- | ||
Severity: | enhancement | CC: | faker.moatamri, mathieu.lacage, ns-bugs, tomh |
Priority: | P4 | ||
Version: | pre-release | ||
Hardware: | All | ||
OS: | All |
Description
Craig Dowell
2009-02-05 13:09:09 EST
The problem with what you describe is that it relies on the user to call Before and After himself so, if we prescribe that these methods must be called, we make all existing scripts invalid. Thus, I have to ask: why can't the user call directly the emu/tap initialization functions at the proper time ? Another option would be to make ::Run call PreRun and PostRun but I am not sure how that would fit with the use of Run+Stop+Run+Stop, etc. To summarize, I don't see any obvious winning solution. (thinking out loud). It might be that this problem is really the responsability of another layer, on top of Simulator. > Thus, I have to ask: why can't the user call directly the
> emu/tap initialization functions at the proper time ?
The user *can* be asked to know that s/he has got to call a certain method at a certain time. We would have to communicate to the user via documentation what that method is and when it should be called; and rely on the user to do it correctly. This introduces an annoying new requirement that is extremely position dependent in a script. I don't think this is good.
I think it is better to *not* export that requirement since the device knows when it needs to be called, how it needs to be called, and knows when it has all of the information it needs. Currently it schedules an event to do it. It works well. The user doesn't need to know anything about it.
It would be nice not to have to place that burden on the user and at the same time not mess up the realtime situation at the first event time.
What I suggest would mean calling a generic function just before Simulator::Run. Compare this with having to understand, for example, if you want to add a tap device you have to call function X with parameters Y and Z just before run; if you want to add an emu device you have to call function X' with parameters a, b, and c; if you want to run some other model, you have to call blah, blah, blah.
IMO, It's a good thing for several reasons
> (thinking out loud). It might be that this problem is really
> the responsability of another layer, on top of Simulator.
That could be certainly be the case. It seems to duplicate some functionality given the existence of Simulator::Destroy.
Unless you want to break out Simulator::Destroy into this new layer.
|