Upcoming plans for CAM

[Scott Long]

All,

Now that the MPSAFE work is mostly done and settled, it's time to move
onto the next phase of the overall work.

NEWBUS integration + Transport modularization:
----------------------------------------------

CAM is centered around parallel SCSI.  It has detailed knowledge of how
buses, targets, and LUNs work in SCSI.  Besides this knowledge being
embedded in the core of CAM, it is not exported out to the NEWBUS
framework.  Running the "devinfo" command only shows the controller
devices, not any of the topology underneath it.  Camcontrol does show
the topology, but that's a privileged command.

My plan is to move the bus scanner and device probe functionality out
of cam_xpt.c and into the scsi/scsi_xpt.c.  As part of this move,
buses, targets, devices, and peripherals will become newbus drivers,
with the normal probe, attach, and detach vectors and semantics.  The
opaque cam_path, cam_eb, cam_et structures will become private to these
newbus drivers.  Access to the internals of these objects will be done
through newbus interface methods.  The XPT will retain knowledge of the
cam_ed structure; keeping it opaque and accessible only though newbus
methods would significantly slow down normal I/O operations.

Topology will be built by parent objects allowing children to probe
and attach themselves to child devices.  Children will probe attributes
such as bus type and device type to decide if they want to claim the
device.  Multiple peripheral devices will still be allowed to attach to
devices, just as today.  Topology will look something like this:

nexus0
   pcib0
     pci0
       sim0
         scsibus0
           target0
             device0
               da0
               pass0
           target1
             device1
               cd0
               pass1
       sim1
         scsibus1
           target2
             device2
               da1
               pass2

I haven't decided yet if the newbus names of the bus, target, and
devices will correspond to actual B:T:L enumeration numbers of if
they'll just be assigned sequentially as they are discovered.
Camcontrol will still show actual B:T:L enumeration, regardless of
what newbus sees.

The end result is that the XPT will be divided into 2 parts, one that
manages topology and advertises devices, and another that manages the
sim and device queues.  This split will not affect the /dev/xpt0 device.
Applications will still only see 1 XPT node, but xptioctl() will
redirect transport-specific commands as needed.  I expect most of this
work to be transparent to userland CAM apps.  There will likely be a
small API change to SIMs to export the SIM newbus device node up so that
children can be attached to it.

SATA and IDE transports, ATA protocol
-------------------------------------

The transport modularization work described above will allow non-SCSI
transports to be easily added.  So, the next step is the long-promised
unification with IDE and SATA.  Instead of hacks like atapicam and
atacam that try to force IDE/SATA into the SCSI model, a whole new
subtransport will be written that understands the topology and nature of
the devices, as well as natively understanding the ATA command set.

There are still some interesting design questions that need to be
answered here.  SATA controllers essentially use a star topology instead
of a bus topology.  So does it make sense to treat all devices as each
having a private bus, or is it better to have a single virtual bus?
Also, ATAPI devices basically speak the SCSI protocol so they'll attach
to things like the 'cd' driver, but ATA disks speak ATA, which is very
different from SCSI.  Should they get their own unique peripheral
device, or should they be part of the 'da' device?  If they get their
own peripheral device, should they still generate '/dev/da' device
nodes, or should they retain the current '/dev/ad' naming?

The SIM drivers for IDE/SATA will use the same interface as SCSI.  They
will be responsible for programming the controller, managing command
timeouts, and performing transport level error detection and recovery,
just like SCSI SIMs.  Instead of a single monolithic driver that knows
how to talk to dozens of very different controllers, support will be
broken down into multiple SIMs, each targeted to individual controller
families.  I plan to write SIMs for AHCI, ICH2/3/4, and ICH5/6
controllers.

There are no plans to retire the existing ATA driver anytime soon.  It
still contains the best support for tricky, buggy hardware, as well as
older hardware.  The future of these drivers will depend on how well
they serve the community.

Please let me know if you have any questions, objections, or
suggestions.

SCott