Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

smart: Clarify use of ID_ATA_SMART_ACCESS udev property #1063

Merged
merged 1 commit into from
Sep 27, 2024
Merged

smart: Clarify use of ID_ATA_SMART_ACCESS udev property #1063

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 24 additions & 10 deletions src/plugins/smart/smart-common.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,16 +130,30 @@
*
* ## Device type detection, multipath #
*
* There's a big difference in how a drive is accessed. While libatasmart performs
* essentially no device type detection and sends a I/O request right away
* (with usual error handling), `smartctl` implements a logic to determine which
* protocol to use, supporting various passthrough mechanisms and interface bridges.
* Such detection is not always reliable though, having known issues with `dm-multipath`
* for example. For this case most plugin functions provide the `'extra'` argument
* allowing consumers to provide specific arguments such as `'--device=' for device
* type override`. This is only supported by the smartmontools plugin and ignored
* by the libatasmart plugin.
*
* There's a big difference in how a drive is accessed. While `libatasmart` performs
* only very basic device type detection based on parent subsystem as retrieved from
* the udev database, `smartctl` implements logic to determine which protocol to use,
* supporting variety of passthrough mechanisms and interface bridges. Such detection
* is not always reliable though, having known issues with `dm-multipath` for example.
*
* For this case most plugin functions consume the `extra` argument allowing
* callers to specify arguments such as `--device=` for device type override. This
* is only supported by the smartmontools plugin and ignored by the libatasmart
* plugin.
*
* As a well kept secret libatasmart has historically supported device type override
* via the `ID_ATA_SMART_ACCESS` udev property. There's no public C API for this and
* libblockdev generally tends to avoid any udev interaction, leaving the burden
* to callers.
*
* Valid values for this property include `auto`, `linux-ide`, `sat16`, `sat12`,
* `sunplus`, `jmicron`.
*
* A common example to override QEMU ATA device type, which often requires legacy
* IDE protocol:
* |[
* KERNEL=="sd*", ENV{ID_VENDOR}=="ATA", ENV{ID_MODEL}=="QEMU_HARDDISK", ENV{ID_ATA}=="1", ENV{ID_ATA_SMART_ACCESS}="linux-ide"
* ]|
*/

/**
Expand Down