🚀 go-pugleaf

In article <920723102406.10041@hfrd.dsto.gov.au> DALL@hfrd.dsto.GOV.AU writes:
>pc532@bungi.com writes:
> > Soon, I hope, the folks working with Mach on the PC532
> > will be able to make their work available to those without
> > UNIX source licences.
>
>The micro kernel is free of nasty licences, the unix server isn't.
>
>There are a number of possibilities for a licence free server.
>As I understand it, these are the CMU multi server, the GNU Hurd
>and the BSD Net2 based server. The last one has the most hope
>of being available early and had been done for the 386.
>
>It wouldn't be too big a job to do the PC532 port, but I don't
>know of anyone actually doing it.
>
SO noone is actually already working on this project?  I've been playing (yea
its playing since Im not getting paid for it :), with Mach a great deal recently.  Something like this would be a fun project, (so i've got a wierd sense of fun :)
I'd be willing to tackle such a project,  However if others are already
working on it please speak up! no sense duplicating work (I'll offer to help).
Also, I do not currently Own a PC532 , I am working on the solution to that
however.  PLEASE if someone is already working on a mach - PC532 project
let me know!

>
> > When that happy day comes, I'd like
> > to use the SCSI bus as an IPC channel between my PC532 and
> > my NeXT.  What do people think of this idea?
>
>Well, we all want to use SCSI as an IPC bus. I've got this
>Sun 3/50 I want to talk to.
>
> > I already plan
> > to write the relevant drivers,
>
>We are using a layered approach to the scsi drivers. There is a
>machine dependent part, a machine and scsi device independent part and
>a SCSI device (disk, tape, cpu, communications) dependent parts.  The
>support for SCSI 2 cpu and communication devices is being added by CMU
>people (Alessandro Forin).
>
>Write the machine dependent parts and everything else should work for
>free, in theory. In practice, I can't get tapes to work yet.
>
>Our machine dependent SCSI code still needs work. The HUT guys did the
>original work and I am trying to clean up/debug it with as much time
>as I can spare.  Currently we don't support disconnect/reselect or
>target mode. The former is pretty essential from a performance point
>of view and the latter is essential for scsi2 cpu and communication
>devices.
>
> > but what schemes are there for
> > sharing compute power between dissimilar processors?
>
>The most promising is NORMA. I forget what it actually stands for, but
>basically (from memory) it allows memory objects to be shared over a
>network as if it were on the same machine. I think it even fixes up
>byte order problems etc. You can, apparantly, write a process to take
>advantage of multi-cpu and it works the same whether the CPU's are
>tightly coupled or very loosly (NORMA) coupled.
>
>This sounds very nifty. The only published performance figures were
>over ethernet. They got linear speed up for some sorts of problems
>up to about 4 processors. With SCSI communications, the tradeoffs
>would be different of course and maybe NORMA would be useful
>over a wider class of problems.
>
>(Disclaimer: I have zero experience with NORMA, I just read a paper.)
>
>Ian


Thanks,

Jonathan Smith