josh@pbhye.UUCP (Joshua Stein) (07/01/87)
Has anyone thought of porting Minix to the Mac or is that to wierd? I've always
thought that one of the drawbacks to the Mac was a lack of multi-tasking and
wondered if the work involved in porting Minix to the box would be so great
as to make it not worth the effort? If opinions are that it is an idea to followup what would be involved? Pointers to the necessary areas for changes would be
appreciated. Also any brilliant suggestions (jump off the .... ;-))
--
__
Joshua Stein Pacific Bell "Neat Stuff!!" / --) koo koo ka choo
the usual generic disclaimer goes here /\ ) )
(415) 823-2411 uucp:{ihnp4,dual}!phye!josh | \/ \ radford@calgary.UUCP (Radford Neal) (07/01/87)
In article <1756@pbhye.UUCP>, josh@pbhye.UUCP (Joshua Stein) writes: > Has anyone thought of porting Minix to the Mac or is that to wierd? ... I think it would be nifty to port MINIX to the Mac as a desk accessory. You'd have to modify MINIX a bit to take the bits of time a desk accessory gets when the Mac application calls SystemTask and distribute it to the MINIX processes. IO would be done to a pseudo-disk that was actually a Mac file - you could put in an interface to the Mac's file system later. When the desk accessory is closed, you would write the memory image of all processes to disk, ready to restart when the desk accessory is opened again. The main problem would be the C compiler for MINIX, which would have to generate code that offsets all memory references from an address register. If you did this right, however, you could be secure against wild MINIX processes. This method would allow MINIX to be run concurrently with all your favorite Mac applications, at the drop of a mouse button. Radford Neal
grr@cbmvax.UUCP (George Robbins) (07/02/87)
In article <1756@pbhye.UUCP> josh@pbhye.UUCP (Joshua Stein) writes: >Has anyone thought of porting Minix to the Mac or is that to wierd? I've always >thought that one of the drawbacks to the Mac was a lack of multi-tasking and >wondered if the work involved in porting Minix to the box would be so great >as to make it not worth the effort? The critical item for porting minix to other systems is a working 68000 C compiler and some definitions of how relocation and context switching will be handled on the 68000. According to AST there is a group at Phillips in the Netherlands that is working on a port for the Atari ST. Once it is available, I pretty sure a number of people will jump on it and start ports for both the Amiga and the Mac. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
tim@ism780c.UUCP (Tim Smith) (07/03/87)
In article <2063@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
< >Has anyone thought of porting Minix to the Mac or is that to wierd?
< The critical item for porting minix to other systems is a working 68000 C
< compiler and some definitions of how relocation and context switching will
< be handled on the 68000.
Another issue would be device drivers. The Mac device drivers are
asynchronous, so one might be able to use the disk and serial drivers
from the ROM, unlike the case with the IBM PC. This could simplify
the port. I, for one, hate doing device drivers...
One possible way to do Minix on the Mac would be to have Minix simply
be a Macintosh application.
--
Tim Smith, Knowledgian {sdcrdcf,seismo}!ism780c!timmichael@psy.vu.nl (Michael Felt) (07/17/87)
In article <990@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes: > >> Has anyone thought of porting Minix to the Mac or is that to wierd? ... > > >I think it would be nifty to port MINIX to the Mac as a desk accessory. Nice idea > >The main problem would be the C compiler for MINIX, which would have to >generate code that offsets all memory references from an address register. I have written a couple 'back-ends' for the Amsterdam Compiler Kit (ACK) with various memory models. 1. No seperate I/D 32K limit (all AboveA5). 2. Seperate I/D 32K limit text (aboveA5) 32K limit data (BelowA5) 3. Seperate I/D 'no limit text above A5', 32 K limit BelowA5 - data 4. NonSeperate I/D text & data aboveA5 ' no limit ' 5. Seperate I/D, "classic model", jumptable aboveA5, global data belowA5 The flexibility in memory models is an attribute of EM (Encoding Machine), the intermediate language of ACK. I can give tips, but I can't send sources. Sorry. Sources are not mine to send. >If you did this right, however, you could be secure against wild MINIX >processes. > I have my reservations. Without memory protection a bad pointer from any program can blow another program away. Michael Felt UUCP: michael@vupsy.UUCP {...!mcvax!vupsy!michael} Domain: michael@psy.vu.nl
radford@calgary.UUCP (Radford Neal) (07/18/87)
In article <17@vuecho.psy.vu.nl>, michael@psy.vu.nl (Michael Felt) writes: > >> Has anyone thought of porting Minix to the Mac or is that to wierd? ... > >If you did this right, however, you could be secure against wild MINIX > >processes. > > > I have my reservations. Without memory protection a bad pointer > from any program can blow another program away. > > Michael Felt You may not have quite realized how extreme my conception of offsetting *all* accesses from an address register is. Pointer variables would be 16 bits in size. To use one, you load it into a register and use it as a 16-bit index from an address register. All processes are exactly 64K in size. You don't get to use jsr for subroutine calls; you maintain your own stack in the 64K address process of the process. I'm really disappointed in the lack of response from the net on this one. In case you don't get it, the suggestion that MINIX be ported as a desk accessory was a joke. Just think of all those Mac fanatics who could say "Unix? Oh yeah, I've got a desk accessory for that...". If you really want MINIX to run concurrently with Mac applications, I suggest use of Switcher. However, by no means does this mean that my proposed method is not possible! Radford Neal
BECKER%HUMBER.BITNET@wiscvm.wisc.edu (Bruce Becker) (07/21/87)
Actually your idea is more in keeping with the 8086 achitecture, an has some reflection in the ideas of the MAC segment manager... HOWEVER, it seems a waste of a perfectly good linear address space (lacking in 8086 of course...) It seems that what is missing is tne idea of Memory management, which is probab ly impossible to do in software... Segmented address schemes are a sort of a su bset of that idea, and havin 16 instead of 1 Megs to work with IS atrractive... I'm not sure you need to do much differently on 68000 that on 8086, but the C c ompiler will be interesting from point of view of code generation... good luck, any who choose such approach... cheers, bb