svn commit: r200432 - in stable/8: . contrib/top lib/libusb sbin/atacontrol sys/arm/mv sys/cam/ata sys/cam/scsi sys/conf sys/dev/ata sys/dev/ata/chipsets sys/powerpc/powermac sys/powerpc/psim tools...

[Bruce Simpson]

Alexander Motin wrote:
> Log:
>   MFC r200171, r200182, r200275, r200295, r200359:
>   Introduce ATA_CAM kernel option, turning ata(4) controller drivers into
>   cam(4) interface modules. When enabled, this option deprecates all ata(4)
>   peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers
>   (ada, cd, ...) and interfaces to be natively used instead.
>   
    Does this not mean there are now two AHCI drivers? i.e. ata(4) with 
ATA_CAM, and ahci(4).
    If so, which one is preferred?

    ahci(4) seems subjectively faster (I have not measured it), although 
it has a minor issue on my motherboard with ATI SB700 that it does not 
turn off the HDD activity led.

    I can see though that this could be difficult to roll out/deploy for 
default installations from universal media (-RELEASE disc1, memstick), 
different drivers yield different device names.
    In one embedded product build I've had to deal with, I use atapicam 
just to make sure the kernel expects to mount / from the same device, vs 
when it's booted from an attached USB CDROM drive.

    I'm using GEOM labels on my home systems to deal with this now, 
which was a little tricky to set up, but deals with the problem very 
nicely, as well as making it possible for me to swap disks between 
physical controllers.
    tunefs will return no error when the -L option is used when booted 
into single-user mode -- but if the fs is then mounted, the superblock 
change seems to be lost. In all other cases, rewriting the superblock is 
denied.

Anyway thanks for all your hard work on this so far...

cheers!
BMS