Hi Jason,

long time no see :-)

Jason Thorpe wrote:
[...]
> I agree, and there ARE a lot of problems with the CAM code.  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 valid concern. I wonder if we, or better you and Matthew :-),
can talk to Justin and Ken about this. Maybe it is possible to find a
solution
for this problem. Justin, Ken, what do you think about this?

> 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.

Same here.

The other valid concern was about NetBSD's multi-architecture-support,
especially the amount of drivers which need to be ported. But, IMHO,
if we share the CAM code, we can share the load of writing/porting
drivers
much easier than today.

It would be great, if both, old and new drivers could coexist, though,
to ease the transition to CAM. Is this technically possible?

  Guenther