> For certain classes of controller (basically, if it has a firmware that
> wants/needs to do things itself on its own timeframe, etc. then I've heard
> some of those authors grumbling about the amount of controler moved away from
> the low level driver to the CAM layer).
Umm, I do things in the FreeBSD CAM layer, and I certainly write for a
controller that wants/needs to do things itself, and I have to say that
CAM has made things easier for me, not harder. All the command control
flow crap that you have to do in drivers which I still haven't gotten
right for Linux is completely unnecessary in CAM.
My issues with the CAM *implementation* in FreeBSD haven't got much to od
with a beef about the overall CAM approach- they're more of a clarity and
documentation issue where the authors haven't made clear some intents.
CAM itself is a bit heavyweight- it was for exactly this reason we chose
not to implement it at Sun- it was far more running around and dopey
little byte copies and control flow than made sense at the time (a 25 MHz
sparc being the fastest thing to work with and 4MB a large of memory).
-matt
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
