> Okay. But the user application should be aware of signals:
> on ctrl-c, it needs to tear down the vM, too, or we'll be stuck
> with allocated data (is there no other way ? when I process is
> killed, all its open files are released, no ? we should put
> cleanup stuff in fmw_release()).
It is already, isn't it? In any case, it is absolutely necessary
that the kernel part is able to clean up correctly, *without* needing
to rely on any action on part of the user app (which could be killed
with kill -9 or whatever ..).
> > By the way, the soft_int self-modifying code is not particularly
> > SMP-safe (but then again, the whole module isn't ...) ;-)
>
> Hmmm... why not ? What can we do about that ?
Well, as long as only one thread ever accesses the module, we should
be fine. As soon as we need concurrent access (we are planning to
allow multiple VM boxes open at the same time, aren't we?), we'll
need to get rid of all those global variables and also self-modifying
code (which in a way *is* a global variable), and either use private
data (hanging off the 'file' or 'inode' struct) and/or protect acceses
using synchronization mechanisms ...
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
