peter@sugar.hackercorp.com (Peter da Silva) (10/23/90)
In article <1410053@hpcvca.CV.HP.COM> abrown@hpcvca.CV.HP.COM (Allen Brown) writes: > My guess: memory protection. If Unix was a process under AmigaDOS > wouldn't any AmigaDOS process be able to write into any Unix memory? I don't see why. You can set the MMU up so the UNIX tasks are read-only, and have read-only access to the rest of the system. More of a problem is that GURUs are scary for UNIX folks. More interesting would be to consider how hard it would be for Commodore to make AmigaOS POSIX compliant. The only hard part is the fork, and if you restrict POSIX compliant programs to a set of calls to a resource-tracking shared library then that would be solvable. In fact posix.library could be written so that it runs tasks in a protected mode when available so that forks would be cheap (otherwise you'd want to defer the forking task until the child exits or execs... with some reasonably long timeout: forks on a 68000 without MMU are ugly... look at how MINIX does it). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
koren@hpfcdc.HP.COM (Steve Koren) (10/26/90)
> I don't see why. You can set the MMU up so the UNIX tasks are read-only, and > have read-only access to the rest of the system. > More of a problem is that GURUs are scary for UNIX folks. > More interesting would be to consider how hard it would be for Commodore to > make AmigaOS POSIX compliant. The only hard part is the fork, and if you > restrict POSIX compliant programs to a set of calls to a resource-tracking > shared library then that would be solvable. In fact posix.library could be There are a couple of issues here. First of all, making Commodore's Un*x POSIX compliant is definately within the realm of possibility. After all, it is a Un*x. As for making AmigaDos POSIX compliant, which part of your post seems to imply, this is not trivial. There is more to POSIX than the library calls which could be defined in a shared library. That is simply POSIX.1. There is also POSIX.2 and POSIX.2a. Right now, AmigaDos has pretty much none of the stuff necessary for either .2 or .2a. It would be lots and lots of work to get this stuff running, and it would introduce many other problems like dramatically increasing the size of the AmigaDos distribution. It is not impossible, of course. But at the point when you have POSIX compliance for .1, .2, and .2a, then you basically have the complexity of a Un*x system and have to deal with it accordingly. I guess you could just ignore .2 and .2a completely... (Also, neither .2 or .2a is really stable yet.) - steve
peter@sugar.hackercorp.com (Peter da Silva) (10/28/90)
In article <11640024@hpfcdc.HP.COM> koren@hpfcdc.HP.COM (Steve Koren) writes: > As for making AmigaDos POSIX compliant, which part of your post seems to > imply, this is not trivial. There is more to POSIX than the library calls > which could be defined in a shared library. That is simply POSIX.1. True, but it's the hardest part. Once it's done most of POSIX.2 would fall right out of comp.sources.unix and uunet. And a lot of it can be safely ignored if you don't have a UNIX kernel to feed. > It would be lots and lots > of work to get this stuff running, and it would introduce many other > problems like dramatically increasing the size of the AmigaDos distribution. But increasing it with *useful* stuff. Stuff that most of us are having to dig out of Fish disks and comp.sources.amiga. > It is not impossible, of course. But at the point when you have POSIX > compliance for .1, .2, and .2a, then you basically have the complexity > of a Un*x system and have to deal with it accordingly. What complexity? UNIX itself is pretty simple... much simpler than AmigaOS. If you don't carry the tons of warts that System V and BSD have accumulated over the years it's no problem at all. Having a bunch of UNIX programs isn't inherently any more complex than having a stack of Fish disks. > (Also, neither .2 or .2a is really stable yet.) Another reason to shoot for POSIX.1 first. Let's talk about that... The only really *hard* part of it is fork(). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.