“device ada” – obsolete?

olli@

olli@

Developer
I just noticed that I still have “device ada” in my custom kernel’s configuration; it has been sitting there for ages. This is amd/64, and right now I’m on 13.2-STABLE (fetched and built a few months ago).

The kernel configures and builds fine without error messages, so “device ada” still seems to be supported. It’s mentioned in sys/conf/files, and the ada(4) manual page still exists, but it’s not documented anywhere else, and it’s not in any of the distributed configuration files (neither GENERIC nor DEFAULT nor NOTES), so it appears to be obsolete, but I can’t tell for sure.

Can anyone shed some light on this? Does “device ada” have any effect in the kernel configuration? Can I safely remove it? Would that change anything about my devices, i.e. would I have to change my /etc/fstab?

Here’s what dmesg says about my storage devices:
Rich (BB code): 
nda0 at nvme0 bus 0 scbus9 target 0 lun 1
nda0: <CT2000P1SSD8 [...]>
nda0: nvme version 1.3 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda0: 1907729MB (3907029168 512 byte sectors)
nda1 at nvme1 bus 0 scbus10 target 0 lun 1
nda1: <Samsung SSD 970 PRO 1TB [...]>
nda1: nvme version 1.3 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda1: 976762MB (2000409264 512 byte sectors)
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <Samsung SSD 870 QVO 8TB [...]> ACS-4 ATA SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 7630885MB (15628053168 512 byte sectors)
ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1: <OCZ-VERTEX2 [...]> ATA8-ACS SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 114473MB (234441648 512 byte sectors)
ada1: quirks=0x1<4K>
 
I've gone through a bunch of GENERIC kernel configurations, from stable/14 all the way back to stable/3. It was never included in any of them.
 
smithi said:
You have two ada devices, ada0 and ada1. Looks like they're needed ...
Click to expand...
I’m aware that there are two ada devices. But these are just standard SATA SSDs, and I’m pretty sure that they would be recognized with the GENERIC kernel, too, even though it does not contain “device ada”.
(Unfortunately I can’t test this now because I do not want to reboot this machine.)
 
SirDice said:
I've gone through a bunch of GENERIC kernel configurations, from stable/14 all the way back to stable/3. It was never included in any of them.
Click to expand...
Ok … So “device ada” doesn’t seem to be required in order to have support for ada devices – but how does this work, i.e. which device entry in the kernel configuration is actually responsible for supporting ada devices?
Also, the entry “device ada” doesn’t cause an error message, so it is recognized, but it is unclear what it does exactly.

It should also be noted that the cam(4) and ada(4) manual pages both imply that “device ada” is required in the kernel in order to get support for this kind of devices, which seems to be wrong. It’s misleading at best.
 
I think it is mentioned in man but never in conf/NOTES.
I don't think deleting it will make a difference.
Before the ada driver was appeared in 8.0R, it was /dev/ad, not /dev/ada.

I have searched a bit for the code, but I am not sure if it is correct.
find /usr/src/sys -type f|xargs 2grep -A3 periph_driver
Code: 
/usr/src/sys/cam/ata/ata_da.c:static struct periph_driver adadriver =
/usr/src/sys/cam/ata/ata_da.c-{
/usr/src/sys/cam/ata/ata_da.c-  adainit, "ada",
/usr/src/sys/cam/ata/ata_da.c-  TAILQ_HEAD_INITIALIZER(adadriver.units), /* generation */ 0[/cmd]
 
olli@ said:
Ok … So “device ada” doesn’t seem to be required in order to have support for ada devices – but how does this work, i.e. which device entry in the kernel configuration is actually responsible for supporting ada devices?
Click to expand...
device ahci ahci(4) as used for current SATA devices when an AHCI controller is present and enabled:

olli@ said:
I just noticed that I still have “device ada” in my custom kernel’s configuration; it has been sitting there for ages.
Click to expand...
I guess, that entry might be from pre ahci(4) support; either from a motherboard without AHCI controller or pre-FreeBSD 8.0 as its first appearance mentioned in ahci(4).
 
So, "device ada" brings in the CAM ata protocol driver for mass storage. It will also be included if your kernel has "device da" in it. But both of these require a "device scbus" to bring them in. If you don't have one of these, it won't be in your kernel. However, if you have no cam in your kernel, then cam.ko will load and you'll get it via that route.

The old, obsolete stuff you are thinking of is 'device ata', which is still in the tree, but did transition from having its own storage subsystem to using cam in around FreeBSD 9 or so.

So the heirarchy: ahci (or mps, mpt, or other HBA) is a CAM SIM. It attaches to the PCI bus. It creates a number of protocol busses (in ahci case, only a ATA bus) which is handled by the CAM XPT layer (which is configured with the "device scbus" line in your kernel). That layer will notice devices that the SIM tells it about and will use the ada periph driver (configured with "device da" or "device ada") to attach disks it finds, and publish them to the system via /dev/adaXXX for GEOM and Filesystems to use.

So it's the modern, right thing to be using, and if you remove device ada from the kernel, it should disappear (though through a quirk of history, if you have "device da" it won't due to how the dependencies are specified in sys/conf/files). So if you want your storage, don't do that :)
 
You must log in or register to reply here.
Back
Top