> 
> > Is it possible that the only machine dependent requirement is the
> > acquisition of the DMA bounce buffers ?
> 
> as i've said before, NO.
> 
> There are a lot of other machine-dependent, and even "hardware that's
> in your machine"-dependent requirements.
> 
> for instance, should 'inw' and 'outw' byte-swap their arguments,
> and/or how should they be swizzled to poke into memory at the right
> place?   as i understand it, the need to byte swap on amiga ISA
> bridges is dependent on which particular bridge you're using.
> Everything about how to do inw, outw, inb, outb, etc., is
> machine-dependent on the alpha, from: what _BUS_ to do it on
> (there can be mutiple ISA/EISA/PCI busses on some alpha systems!),
> to what bit positions in the word written to memory the data has to go
> in.

I've been kinda following this thread, and wanted to contribute one
more port which will be using ISA DMA: the CHRP (Common Hardware
Reference Platform) one. True, it hasn't been announced yet, and
spec-compliant machines are 6 to 12 months away, but it's the direction
Apple's going, Motorola's going, part of IBM's going, and the
reason I've put off getting a new Mac; mine will be CHRP-compliant.

The outline of the spec is one or more PowerPC's on a PCI bus connected
to a PCI-ISA bridge. A chip on the PCI side impliments most of the
Mac's hardware, and chips on the ISA side do most of a PC's (such as
soundblaster-compatable audio, COM1-COM4, LPT1, PC keyboard, etc.)
I/O. Most of the IO will be accessable little-endianly and
big-endianly (the video buffer in particular).

Since the machines are a ways off, I'm just wanting to say that eventually
making platform-independent code will be a big win.

[more details of points-of-pain deleted]
> I don't think it's a good thing to say "these ports are not yet done"
> (some of them _are_ nearly "done," and by the "is it all in the source
> tree metric, the Alpha port isn't even done!) when determining how to
> properly implement an ISA bus abstraction to be used by
> machine-independent drivers.  Otherwise, you'll end up rewriting much
> of the ISA code N times, where N is probably log2 of the number of
> ports that use it.

True, but I would like to suggest that, in the beginning, a bit of this
duplicity might be good. As many might have guessed, I'm involved with
the mac68k port. We (I) just ported the serial driver from the sun/sparc
ports, after much hacking. Now, for a second pass, I'm going to go
back and do it again. Also, there's an effort to make a machine-indep.
z8530 chip driver, and a lot of what I've learned will (hopefully :-)
enhance the M.I. effort. So try something, and see what works. Maybe
iterative-refinement w/ occasional massive rewrites would be best?

Take care,

Bill