On Wed, Dec 31, 2003 at 03:37:44PM +0100, Manuel Bouyer wrote:
> On Tue, Dec 30, 2003 at 09:46:55AM -0800, Eivind Eklund wrote:
> > [... lots of stuff about how to change the NetBSD drivers to support
> > SATA ...]
> > 
> > This sounds like it might be more work than snarfing the FreeBSD ATA
> > drivers, which I believe already supports a full superset of what the
> > NetBSD drivers support (but I may be wrong, of course.)  The FreeBSD
> > drivers are also very well maintained - Søren has been doing an
> > outstanding job.
> > 
> > There might be things that block switching that I don't know about (or
> > it may be more work), of course - but it would be nice to converge
> > instead of diverge.
> 
> In addition to what Jason already said, there's lot of work to get the FreeBSD
> IDE system ready for NetBSD, it's too i386-centric.

Eh?  We use it on all platforms - specifically, I know it is in use on
i386, pc98, alpha, sparc64, and amd64.  There are some small bits of
code that are specific for each of alpha, sparc64, and pc98, but these
seem to be there to work around brokenness on each platform.

If there are other issues WRT our portability I don't know of, I'm
curious of them.  (We don't have specific adaptions for ATA on other
platforms, of course, and it may be that our platforms as a group are so 
homogenous that this bring up issues I don't know of.)

> Also, the autoconf system is completely different, which makes it harder to
> share code.

True - this was the amount of work I was referring to.  We don't use
autoconf, as it was deemed to inflexible - but I don't think the client
end of newbus (the technology FreeBSD uses instead of autoconf) has
additional complexity that would make the port too hard.

The point Jason takes up with merged SCSI/IDE layer is more of an issue
(and probably enough to shoot the concept down as unrealistic).  I had
forgotten that NetBSD had done this.  FreeBSD do merge the ATAPI
capabilities under CAM[1], but I believe that is done as a different
entry to the ATA drivers than normal.  And CAM wouldn't really help much
- AFAIR, NetBSD never did the CAM switch, but instead took a different
route for SCSI development.

Eivind.

[1] For those not into FreeBSD: the CAM (Common Access Method) code
    replaced the entire generic SCSI subsystem which NetBSD and FreeBSD
    shared.  The replacement gives three layers: "Generic CAM"
    which has an interface designed for access to storage devices.  This
    includes both Direct Access devices (disks et al) and Sequential
    Devices (tapes et al).  Beneath this is a new SCSI layer, which
    required that all SCSI drivers etc was replaced.  CAM includes a lot
    of timeout support etc, which percolates down almost into the
    drivers.  The ATA layer is implemented separately, and includes its
    own timeout code etc, but with a special set of entry points that
    makes ATAPI available through CAM, too.  This means that ATA code is
    fairly self contained, and this was what I visualized bringing over.