> > Solve problems rather than assign blame.
>
>I agree, and there ARE a lot of problems with the CAM code.

Lots == 2?  Seems like a glowing recommendation!

>The one
>that jumps to mind immediately is its autoconfiguration model.  There is
>a lot of machinery in Justin's CAM code to handle e.g. cloning devices,
>which our autoconfiguration already supports in a generic way.

This is a red herring.  95% of the probing code provided by CAM is required
regardless of your configuration model.  The only difference the
configuration model makes is who calls the bus scanning, etc. functions,
from where, and the mechanism used to store and lookup driver instances.  I
think that converting the code to 'new config' would be relatively easy
since the hooks provided by FreeBSD CAM are almost exactly what you need
for this.  For optimum performance, you'd want to add a mechanism to new
config to allow for bus attachment to be deferred until after interrupt
services are available since CAM uses this to greatly reduce system boot
time.

>There is also the issue of having a separate "passthru" node for devices
>on the bus.  What is the rationale for this?  Let's say I'm an application
>writer, and I want to send arbitrary commands to "cd0".  I have to hunt
>to find the passthru node (which may be "pass42") to correspond to my
>device.  Seems unnecessary.

This all boils down to a very simple philosophy.  Why should one client of
a device (the CD driver), need to do extra work to support another client
of that device (Pass Thru driver) other than to be able to express at times
the need for exclusive access to the underlying device.  The answer is, it
shouldn't.  Having multiple peripheral drivers talking to the same
underlying device in CAM is quite common (Device Probe Driver during bus
scans, Pass-through Driver, the 'real' driver) and because of this
architecture doing things like pass-thru or having a worm and cd driver
share a device simply falls out.  The problem about finding the correct
pass through device is really an administrative issue that can be solved
using tools provided by the CAM XPT device node.

--
Justin