Bug 194209 - ahciems should be optional (at build or at run time)
Summary: ahciems should be optional (at build or at run time)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-07 03:16 UTC by Enji Cooper
Modified: 2014-10-13 19:35 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer 2014-10-07 03:16:24 UTC
The code in sys/dev/ahci.c automatically detects whether or not a device has
AHCI_CAP_EMS support, then automatically loads the ahciem device. The ahciem device should instead be loaded in the default kernel as a dependency of ahci.

310 	if (ctlr->caps & AHCI_CAP_EMS) {
311 	    child = device_add_child(dev, "ahciem", -1);
312 	    if (child == NULL)
313 	        device_printf(dev, "failed to add enclosure device\n");
314 	    else
315 	        device_set_ivars(child, (void *)(intptr_t)-1);
316   	}
Comment 1 Alexander Motin freebsd_committer 2014-10-07 06:35:45 UTC
Not sure I understand your proposition. Do you want ahciem to be separate module, or do you want some tunable to disable it, or something else?
Comment 2 Enji Cooper freebsd_committer 2014-10-13 19:35:16 UTC
(In reply to Alexander Motin from comment #1)
> Not sure I understand your proposition. Do you want ahciem to be separate
> module, or do you want some tunable to disable it, or something else?

I jumped to a conclusion without providing a proper problem statement.

Basically we have a platform at work that has ahciems support, but our software isn't coded up to handle ahciems currently, so this causes our software to poke at the boot drives for ahciems status a little too much.

Having the support on by default makes sense from a usability perspective. In general, being able to enable/disable ahciems on a global or a per-controller basis (like atc.wc.enable) is desirable, because the end-user might not want ahciems support to be enabled, or the device support provided/integrated in with some vendors might be buggy/broken.

PS I was working on a patch to separate out the drivers, but then I realized that it would introduce unnecessary complexity because of how the driver currently hangs ahciems devices off of ahci controllers, and how the ahciems instances are created/destroyed at ahci controller attach/detach.