Date: Sat, 12 Dec 2009 11:52:54 +0000 From: Bruce Simpson <bms@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-8@freebsd.org Subject: Re: 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... Message-ID: <4B238416.5070904@FreeBSD.org> In-Reply-To: <200912121037.nBCAbVeh048839@svn.freebsd.org> References: <200912121037.nBCAbVeh048839@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B238416.5070904>