Jeff Dike wrote:
> There are sure some ugly things in there. On the plus side, they are also
> fairly creative :-)
umlsim-1 should already be a little better ;-) (It doesn't handle
"timeless" events like softirqs very well, though.)
> My thinking on this is to encapsulate all of the time code into a virtual
> rtc driver.
That would be cleaner in some ways, yes. However, there are a few more
things I want umlsim to do:
- skip pauses very quickly. umlsim even increments jiffies directly,
without timer interrupt, if there's nothing else to do. This will
help people testing long-running timeouts. That's why I'm
listening to timers. (I need high-resolution timers for the
simulation part anyway, so this isn't such a big extra cost.)
- spend as little virtual time as possible, e.g. don't advance time
for softirqs or such. A virtual RTC would have to be about as
intrusive as the current code for this. This is pretty much a
requirement for deterministic simulation.
- not related to time: place a set of breakpoints, then wait until
one of them gets triggered, then pick a new set of breakpoints
and/or switch to a different virtual CPU and repeat. That way, I
hope to exercise race conditions (see also the modules discussion
One of the reasons why I picked idle_sleep as my central attachment
point was that I want to be sure the system is completely idle (that
is, as far as I choose to control it), i.e. that is has completed
whatever it could do before the next timer tick. Most of the rest
follows from there.
SIGALRM vs. SIGVTALRM could use better abstraction, though. But first,
I need to understand better why you're alternating between the two in
the first place :-)
I haven't looked at mconsole yet. My current design won't work well
for SMP, so I'll definitely need better abstraction at that point.
> This driver would normally take input from an interval timer,
> but could also be set to take input from an mconsole client. In this mode,
> the mconsole client would send a 'tick' command as often as it wanted the
> UML clock to tick. So, it would be in complete control of the UML's time.
There's more: softirqs run off any interrupt, so they may occur
between timer ticks. The simulation may also do things between timer
ticks (e.g. generate a packet) that activate softirqs (tasklets, BHs,
etc.). All this must be as deterministic as possible (i.e. repeated
runs must yield the same result; there may be slight variations
But I agree that just firing off a signal for each clock tick is
neither efficient nor robust.
An example for lack of determinism: umlsim init=/bin/date returns
wildly differing dates. I think this is caused by softirqs riding
on periodic timers.
> This would also allow time to go backwards. I don't know if there is any
> demand for this, but the possibility would be there.
Give VIA some new ideas ? ;-)
/ Werner Almesberger, Buenos Aires, Argentina wa@... /