@Hans_
Libraries are generally written such that the application holds the data itself.
Unfortunately this is not the case. Most libraries maintain library side data structures which are shared between different callers. These require total rewrite in MP environment.
But how many of the device APIs actually pass pointers to the driver internals? The input device, timer device and others definitely don't. Their message internals could remain the same.
Except that the messaging system must go (see below), which means the device interface will change, too. -> rewriting tons of code.
Exec Message passing
Well, obviously. But what kind of a change are you thinking of? I'd expect the message passing by reference to continue, but with a requirement that the entire contents of a message must be in shared mem (or temporarily shared mem, if possible), and the message receiver isn't allowed to cache pointers (i.e., after a reply message, it no longer has access).
I was merely pointing out the problems, not suggesting any ways to fix them (yes, this is much easier, I know :-)). Since the actual message can contain arbitrary data (say pointers to even more data elsewhere in memory!), it's impossible to re-use this concept in an MP environment. This is one of the largest problems since it means ALL message passing code must be rewritten everywhere. And this problem is extremely widespread since messages are in the core of pretty much every other OS component and application.
Don't IRQ handlers operate in kernel space? If so, what's the issue?
They call user code directly. Assuming each process has it's own memory space this just won't work at all.
How many would involve data crossing over process boundaries? Yes, those would be a real pain.
Most. There are couple of context dependant pointers passed to the hook function for example, and the hooks again call other process' code from the context of either another. Total mess from MP POV. This means hooks must go too, so anything using them must be rewritten.
Exactly what is the difficulty with expanding ints to int64s? We're breaking compatibility anyway, so keeping structure alignment isn't necessary.
Assuming AmigaOS, all of the existing code is hardcoded to 32bit ints (pointer sizes mostly). AROS situation is better here, but AFAIK not everything is fixed yet.
To get things started, you'd need the new exec kernel and a set of device drivers running before the sandbox could be put in place.
Device drivers alone won't do it I'm afraid. Or are you suggesting the sandbox would somehow use the drivers directly? That'd lead to double work since you'd then need to somehow access them from
both the sandbox and the new OS itself. Also, not many device drivers handle two simultanous accessors well (for example imagine two OSes fighting over the access to HDD, display framebuffer and input devices). This plan smells of disaster.
One way or another one of the OSes must explicitly manage the actual hardware resources, and then provide them in a safe, controlled manner to the other. If you plan to have MP, this manager can't be the sandbox -> you must have pretty advanced new OS before the sandbox can work.
