> Date: Thu, 24 Apr 1997 10:44:11 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
>
> > In any event, I think that the rtlinux soft-interrupts fits into
> > this scheme quite well and should make the irq_lock unecessary.
>
> I don't believe you can make the irq_lock unnecessary - _something_
> like that is needed anyway.
>
> Unless you want to make our drivers require knowledge of SMP safety,
> something we specifically do not want, it is a huge win to completely
> hide the details of SMP from driver writers.
too bad that synronize_irq() thing happens at least once every driver ...
i've been thinking hard how to detect such situations atomatically, and
what about this scheme:
surely there is no theoretical solution, but there is a very nice
profiling-driven solution: to build a per-driver 'EIP color map', which
works similarly to profiling, but does not build a histogram, just a "i've
been here" map. Now, if people run a driver on uniprocessor for 1 day,
it's 99.9999% chance that the driver/kernel already passed every possible
EIP value. Now this is the point where me make a 'snapshot' of the
'uniprocessor EIP color map'.
then we make the same on SMP, and we compare the results. (the comparing
is not exactly trivial, as we have to back to the C level via gdb, because
the generated binary code is different ... but it's possible and it doesnt
have to be fast or pretty as it happens only during development).
Then we look for areas that are colored in the SMP case, but totally empty
in the uniprocessor case. BINGO, we have semantics that got broken on SMP
--> driver gets fixed.
hm?
Ingo