docs/about/deprecated.rst

   1 .. _Deprecated features:
   2
   3 Deprecated features
   4 ===================
   5
   6 In general features are intended to be supported indefinitely once
   7 introduced into QEMU. In the event that a feature needs to be removed,
   8 it will be listed in this section. The feature will remain functional for the
   9 release in which it was deprecated and one further release. After these two
  10 releases, the feature is liable to be removed. Deprecated features may also
  11 generate warnings on the console when QEMU starts up, or if activated via a
  12 monitor command, however, this is not a mandatory requirement.
  13
  14 Prior to the 2.10.0 release there was no official policy on how
  15 long features would be deprecated prior to their removal, nor
  16 any documented list of which features were deprecated. Thus
  17 any features deprecated prior to 2.10.0 will be treated as if
  18 they were first deprecated in the 2.10.0 release.
  19
  20 What follows is a list of all features currently marked as
  21 deprecated.
  22
  23 System emulator command line arguments
  24 --------------------------------------
  25
  26 Short-form boolean options (since 6.0)
  27 ''''''''''''''''''''''''''''''''''''''
  28
  29 Boolean options such as ``share=on``/``share=off`` could be written
  30 in short form as ``share`` and ``noshare``.  This is now deprecated
  31 and will cause a warning.
  32
  33 ``delay`` option for socket character devices (since 6.0)
  34 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  35
  36 The replacement for the ``nodelay`` short-form boolean option is ``nodelay=on``
  37 rather than ``delay=off``.
  38
  39 Plugin argument passing through ``arg=<string>`` (since 6.1)
  40 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  41
  42 Passing TCG plugins arguments through ``arg=`` is redundant is makes the
  43 command-line less readable, especially when the argument itself consist of a
  44 name and a value, e.g. ``-plugin plugin_name,arg="arg_name=arg_value"``.
  45 Therefore, the usage of ``arg`` is redundant. Single-word arguments are treated
  46 as short-form boolean values, and passed to plugins as ``arg_name=on``.
  47 However, short-form booleans are deprecated and full explicit ``arg_name=on``
  48 form is preferred.
  49
  50 ``-smp`` (Unsupported "parameter=1" SMP configurations) (since 9.0)
  51 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  52
  53 Specified CPU topology parameters must be supported by the machine.
  54
  55 In the SMP configuration, users should provide the CPU topology parameters that
  56 are supported by the target machine.
  57
  58 However, historically it was allowed for users to specify the unsupported
  59 topology parameter as "1", which is meaningless. So support for this kind of
  60 configurations (e.g. -smp drawers=1,books=1,clusters=1 for x86 PC machine) is
  61 marked deprecated since 9.0, users have to ensure that all the topology members
  62 described with -smp are supported by the target machine.
  63
  64 ``-runas`` (since 9.1)
  65 ----------------------
  66
  67 Use ``-run-with user=..`` instead.
  68
  69
  70 User-mode emulator command line arguments
  71 -----------------------------------------
  72
  73 ``-p`` (since 9.0)
  74 ''''''''''''''''''
  75
  76 The ``-p`` option pretends to control the host page size.  However,
  77 it is not possible to change the host page size, and using the
  78 option only causes failures.
  79
  80 QEMU Machine Protocol (QMP) commands
  81 ------------------------------------
  82
  83 ``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device`` (since 2.8)
  84 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  85
  86 Use argument ``id`` instead.
  87
  88 ``eject`` argument ``device`` (since 2.8)
  89 '''''''''''''''''''''''''''''''''''''''''
  90
  91 Use argument ``id`` instead.
  92
  93 ``blockdev-change-medium`` argument ``device`` (since 2.8)
  94 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  95
  96 Use argument ``id`` instead.
  97
  98 ``block_set_io_throttle`` argument ``device`` (since 2.8)
  99 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 100
 101 Use argument ``id`` instead.
 102
 103 ``blockdev-add`` empty string argument ``backing`` (since 2.10)
 104 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 105
 106 Use argument value ``null`` instead.
 107
 108 ``block-commit`` arguments ``base`` and ``top`` (since 3.1)
 109 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 110
 111 Use arguments ``base-node`` and ``top-node`` instead.
 112
 113 ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
 114 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 115
 116 Use the more generic commands ``block-export-add`` and ``block-export-del``
 117 instead.  As part of this deprecation, where ``nbd-server-add`` used a
 118 single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.
 119
 120 ``query-qmp-schema`` return value member ``values`` (since 6.2)
 121 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 122
 123 Member ``values`` in return value elements with meta-type ``enum`` is
 124 deprecated.  Use ``members`` instead.
 125
 126 ``drive-backup`` (since 6.2)
 127 ''''''''''''''''''''''''''''
 128
 129 Use ``blockdev-backup`` in combination with ``blockdev-add`` instead.
 130 This change primarily separates the creation/opening process of the backup
 131 target with explicit, separate steps. ``blockdev-backup`` uses mostly the
 132 same arguments as ``drive-backup``, except the ``format`` and ``mode``
 133 options are removed in favor of using explicit ``blockdev-create`` and
 134 ``blockdev-add`` calls. See :doc:`/interop/live-block-operations` for
 135 details.
 136
 137 Incorrectly typed ``device_add`` arguments (since 6.2)
 138 ''''''''''''''''''''''''''''''''''''''''''''''''''''''
 139
 140 Due to shortcomings in the internal implementation of ``device_add``, QEMU
 141 incorrectly accepts certain invalid arguments: Any object or list arguments are
 142 silently ignored. Other argument types are not checked, but an implicit
 143 conversion happens, so that e.g. string values can be assigned to integer
 144 device properties or vice versa.
 145
 146 This is a bug in QEMU that will be fixed in the future so that previously
 147 accepted incorrect commands will return an error. Users should make sure that
 148 all arguments passed to ``device_add`` are consistent with the documented
 149 property types.
 150
 151 QEMU Machine Protocol (QMP) events
 152 ----------------------------------
 153
 154 ``MEM_UNPLUG_ERROR`` (since 6.2)
 155 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 156
 157 Use the more generic event ``DEVICE_UNPLUG_GUEST_ERROR`` instead.
 158
 159 ``vcpu`` trace events (since 8.1)
 160 '''''''''''''''''''''''''''''''''
 161
 162 The ability to instrument QEMU helper functions with vCPU-aware trace
 163 points was removed in 7.0. However QMP still exposed the vcpu
 164 parameter. This argument has now been deprecated and the remaining
 165 remaining trace points that used it are selected just by name.
 166
 167 Host Architectures
 168 ------------------
 169
 170 BE MIPS (since 7.2)
 171 '''''''''''''''''''
 172
 173 As Debian 10 ("Buster") moved into LTS the big endian 32 bit version of
 174 MIPS moved out of support making it hard to maintain our
 175 cross-compilation CI tests of the architecture. As we no longer have
 176 CI coverage support may bitrot away before the deprecation process
 177 completes. The little endian variants of MIPS (both 32 and 64 bit) are
 178 still a supported host architecture.
 179
 180 System emulation on 32-bit x86 hosts (since 8.0)
 181 ''''''''''''''''''''''''''''''''''''''''''''''''
 182
 183 Support for 32-bit x86 host deployments is increasingly uncommon in mainstream
 184 OS distributions given the widespread availability of 64-bit x86 hardware.
 185 The QEMU project no longer considers 32-bit x86 support for system emulation to
 186 be an effective use of its limited resources, and thus intends to discontinue
 187 it. Since all recent x86 hardware from the past >10 years is capable of the
 188 64-bit x86 extensions, a corresponding 64-bit OS should be used instead.
 189
 190
 191 System emulator CPUs
 192 --------------------
 193
 194 ``power5+`` and ``power7+`` CPU names (since 9.0)
 195 '''''''''''''''''''''''''''''''''''''''''''''''''
 196
 197 The character "+" in device (and thus also CPU) names is not allowed
 198 in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``,
 199 ``power7+`` and ``power7+_v2.1`` are currently still supported via
 200 an alias, but for consistency these will get removed in a future
 201 release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead.
 202
 203 ``Sun-UltraSparc-IIIi+`` and ``Sun-UltraSparc-IV+`` CPU names (since 9.1)
 204 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 205
 206 The character "+" in device (and thus also CPU) names is not allowed
 207 in the QEMU object model anymore. ``Sun-UltraSparc-IIIi+`` and
 208 ``Sun-UltraSparc-IV+`` are currently still supported via a workaround,
 209 but for consistency these will get removed in a future release, too.
 210 Use ``Sun-UltraSparc-IIIi-plus`` and ``Sun-UltraSparc-IV-plus`` instead.
 211
 212 CRIS CPU architecture (since 9.0)
 213 '''''''''''''''''''''''''''''''''
 214
 215 The CRIS architecture was pulled from Linux in 4.17 and the compiler
 216 is no longer packaged in any distro making it harder to run the
 217 ``check-tcg`` tests. Unless we can improve the testing situation there
 218 is a chance the code will bitrot without anyone noticing.
 219
 220 System emulator machines
 221 ------------------------
 222
 223 Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
 224 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 225
 226 The ``dtb-kaslr-seed`` property on the ``virt`` board has been
 227 deprecated; use the new name ``dtb-randomness`` instead. The new name
 228 better reflects the way this property affects all random data within
 229 the device tree blob, not just the ``kaslr-seed`` node.
 230
 231 ``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
 232 '''''''''''''''''''''''''''''''''''''''''''''''''''''
 233
 234 These old machine types are quite neglected nowadays and thus might have
 235 various pitfalls with regards to live migration. Use a newer machine type
 236 instead.
 237
 238 ``shix`` (since 9.0)
 239 ''''''''''''''''''''
 240
 241 The machine is no longer in existence and has been long unmaintained
 242 in QEMU. This also holds for the TC51828 16MiB flash that it uses.
 243
 244 ``pseries-2.1`` up to ``pseries-2.12`` (since 9.0)
 245 ''''''''''''''''''''''''''''''''''''''''''''''''''
 246
 247 Older pseries machines before version 3.0 have undergone many changes
 248 to correct issues, mostly regarding migration compatibility. These are
 249 no longer maintained and removing them will make the code easier to
 250 read and maintain. Use versions 3.0 and above as a replacement.
 251
 252 Arm machines ``akita``, ``borzoi``, ``cheetah``, ``connex``, ``mainstone``, ``n800``, ``n810``, ``spitz``, ``terrier``, ``tosa``, ``verdex``, ``z2`` (since 9.0)
 253 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 254
 255 QEMU includes models of some machine types where the QEMU code that
 256 emulates their SoCs is very old and unmaintained. This code is now
 257 blocking our ability to move forward with various changes across
 258 the codebase, and over many years nobody has been interested in
 259 trying to modernise it. We don't expect any of these machines to have
 260 a large number of users, because they're all modelling hardware that
 261 has now passed away into history. We are therefore dropping support
 262 for all machine types using the PXA2xx and OMAP2 SoCs. We are also
 263 dropping the ``cheetah`` OMAP1 board, because we don't have any
 264 test images for it and don't know of anybody who does; the ``sx1``
 265 and ``sx1-v1`` OMAP1 machines remain supported for now.
 266
 267 PPC 405 ``ref405ep`` machine (since 9.1)
 268 ''''''''''''''''''''''''''''''''''''''''
 269
 270 The ``ref405ep`` machine and PPC 405 CPU have no known users, firmware
 271 images are not available, OpenWRT dropped support in 2019, U-Boot in
 272 2017, Linux also is dropping support in 2024. It is time to let go of
 273 this ancient hardware and focus on newer CPUs and platforms.
 274
 275 Backend options
 276 ---------------
 277
 278 Using non-persistent backing file with pmem=on (since 6.1)
 279 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 280
 281 This option is used when ``memory-backend-file`` is consumed by emulated NVDIMM
 282 device. However enabling ``memory-backend-file.pmem`` option, when backing file
 283 is (a) not DAX capable or (b) not on a filesystem that support direct mapping
 284 of persistent memory, is not safe and may lead to data loss or corruption in case
 285 of host crash.
 286 Options are:
 287
 288     - modify VM configuration to set ``pmem=off`` to continue using fake NVDIMM
 289       (without persistence guaranties) with backing file on non DAX storage
 290     - move backing file to NVDIMM storage and keep ``pmem=on``
 291       (to have NVDIMM with persistence guaranties).
 292
 293 Device options
 294 --------------
 295
 296 Emulated device options
 297 '''''''''''''''''''''''
 298
 299 ``-device virtio-blk,scsi=on|off`` (since 5.0)
 300 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 301
 302 The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  VIRTIO 1.0
 303 and later do not support it because the virtio-scsi device was introduced for
 304 full SCSI support.  Use virtio-scsi instead when SCSI passthrough is required.
 305
 306 Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an
 307 alias.
 308
 309 ``-device nvme-ns,eui64-default=on|off`` (since 7.1)
 310 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 311
 312 In QEMU versions 6.1, 6.2 and 7.0, the ``nvme-ns`` generates an EUI-64
 313 identifier that is not globally unique. If an EUI-64 identifier is required, the
 314 user must set it explicitly using the ``nvme-ns`` device parameter ``eui64``.
 315
 316 ``-device nvme,use-intel-id=on|off`` (since 7.1)
 317 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 318
 319 The ``nvme`` device originally used a PCI Vendor/Device Identifier combination
 320 from Intel that was not properly allocated. Since version 5.2, the controller
 321 has used a properly allocated identifier. Deprecate the ``use-intel-id``
 322 machine compatibility parameter.
 323
 324 ``-device cxl-type3,memdev=xxxx`` (since 8.0)
 325 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 326
 327 The ``cxl-type3`` device initially only used a single memory backend.  With
 328 the addition of volatile memory support, it is now necessary to distinguish
 329 between persistent and volatile memory backends.  As such, memdev is deprecated
 330 in favor of persistent-memdev.
 331
 332 ``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
 333 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 334
 335 The 9p ``proxy`` filesystem backend driver has been deprecated and will be
 336 removed (along with its proxy helper daemon) in a future version of QEMU. Please
 337 use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` filesystem
 338 backend, or alternatively consider deploying virtiofsd instead.
 339
 340 The 9p ``proxy`` backend was originally developed as an alternative to the 9p
 341 ``local`` backend. The idea was to enhance security by dispatching actual low
 342 level filesystem operations from 9p server (QEMU process) over to a separate
 343 process (the virtfs-proxy-helper binary). However this alternative never gained
 344 momentum. The proxy backend is much slower than the local backend, hasn't seen
 345 any development in years, and showed to be less secure, especially due to the
 346 fact that its helper daemon must be run as root, whereas with the local backend
 347 QEMU is typically run as unprivileged user and allows to tighten behaviour by
 348 mapping permissions et al by using its 'mapped' security model option.
 349
 350 Nowadays it would make sense to reimplement the ``proxy`` backend by using
 351 QEMU's ``vhost`` feature, which would eliminate the high latency costs under
 352 which the 9p ``proxy`` backend currently suffers. However as of to date nobody
 353 has indicated plans for such kind of reimplementation unfortunately.
 354
 355 RISC-V 'any' CPU type ``-cpu any`` (since 8.2)
 356 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 357
 358 The 'any' CPU type was introduced back in 2018 and has been around since the
 359 initial RISC-V QEMU port. Its usage has always been unclear: users don't know
 360 what to expect from a CPU called 'any', and in fact the CPU does not do anything
 361 special that isn't already done by the default CPUs rv32/rv64.
 362
 363 After the introduction of the 'max' CPU type, RISC-V now has a good coverage
 364 of generic CPUs: rv32 and rv64 as default CPUs and 'max' as a feature complete
 365 CPU for both 32 and 64 bit builds. Users are then discouraged to use the 'any'
 366 CPU type starting in 8.2.
 367
 368 RISC-V CPU properties which start with capital 'Z' (since 8.2)
 369 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 370
 371 All RISC-V CPU properties which start with capital 'Z' are being deprecated
 372 starting in 8.2. The reason is that they were wrongly added with capital 'Z'
 373 in the past. CPU properties were later added with lower-case names, which
 374 is the format we want to use from now on.
 375
 376 Users which try to use these deprecated properties will receive a warning
 377 recommending to switch to their stable counterparts:
 378
 379 - "Zifencei" should be replaced with "zifencei"
 380 - "Zicsr" should be replaced with "zicsr"
 381 - "Zihintntl" should be replaced with "zihintntl"
 382 - "Zihintpause" should be replaced with "zihintpause"
 383 - "Zawrs" should be replaced with "zawrs"
 384 - "Zfa" should be replaced with "zfa"
 385 - "Zfh" should be replaced with "zfh"
 386 - "Zfhmin" should be replaced with "zfhmin"
 387 - "Zve32f" should be replaced with "zve32f"
 388 - "Zve64f" should be replaced with "zve64f"
 389 - "Zve64d" should be replaced with "zve64d"
 390
 391 Block device options
 392 ''''''''''''''''''''
 393
 394 ``"backing": ""`` (since 2.12)
 395 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 396
 397 In order to prevent QEMU from automatically opening an image's backing
 398 chain, use ``"backing": null`` instead.
 399
 400 ``rbd`` keyvalue pair encoded filenames: ``""`` (since 3.1)
 401 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 402
 403 Options for ``rbd`` should be specified according to its runtime options,
 404 like other block drivers.  Legacy parsing of keyvalue pair encoded
 405 filenames is useful to open images with the old format for backing files;
 406 These image files should be updated to use the current format.
 407
 408 Example of legacy encoding::
 409
 410   json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"}
 411
 412 The above, converted to the current supported format::
 413
 414   json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"}
 415
 416 ``iscsi,password=xxx`` (since 8.0)
 417 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 418
 419 Specifying the iSCSI password in plain text on the command line using the
 420 ``password`` option is insecure. The ``password-secret`` option should be
 421 used instead, to refer to a ``--object secret...`` instance that provides
 422 a password via a file, or encrypted.
 423
 424 Character device options
 425 ''''''''''''''''''''''''
 426
 427 Backend ``memory`` (since 9.0)
 428 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 429
 430 ``memory`` is a deprecated synonym for ``ringbuf``.
 431
 432 CPU device properties
 433 '''''''''''''''''''''
 434
 435 ``pcommit`` on x86 (since 9.1)
 436 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 437
 438 The PCOMMIT instruction was never included in any physical processor.
 439 It was implemented as a no-op instruction in TCG up to QEMU 9.0, but
 440 only with ``-cpu max`` (which does not guarantee migration compatibility
 441 across versions).
 442
 443 ``pmu-num=n`` on RISC-V CPUs (since 8.2)
 444 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 445
 446 In order to support more flexible counter configurations this has been replaced
 447 by a ``pmu-mask`` property. If set of counters is continuous then the mask can
 448 be calculated with ``((2 ^ n) - 1) << 3``. The least significant three bits
 449 must be left clear.
 450
 451
 452 Backwards compatibility
 453 -----------------------
 454
 455 Runnability guarantee of CPU models (since 4.1)
 456 '''''''''''''''''''''''''''''''''''''''''''''''
 457
 458 Previous versions of QEMU never changed existing CPU models in
 459 ways that introduced additional host software or hardware
 460 requirements to the VM.  This allowed management software to
 461 safely change the machine type of an existing VM without
 462 introducing new requirements ("runnability guarantee").  This
 463 prevented CPU models from being updated to include CPU
 464 vulnerability mitigations, leaving guests vulnerable in the
 465 default configuration.
 466
 467 The CPU model runnability guarantee won't apply anymore to
 468 existing CPU models.  Management software that needs runnability
 469 guarantees must resolve the CPU model aliases using the
 470 ``alias-of`` field returned by the ``query-cpu-definitions`` QMP
 471 command.
 472
 473 While those guarantees are kept, the return value of
 474 ``query-cpu-definitions`` will have existing CPU model aliases
 475 point to a version that doesn't break runnability guarantees
 476 (specifically, version 1 of those CPU models).  In future QEMU
 477 versions, aliases will point to newer CPU model versions
 478 depending on the machine type, so management software must
 479 resolve CPU model aliases before starting a virtual machine.
 480
 481 QEMU guest agent
 482 ----------------
 483
 484 ``--blacklist`` command line option (since 7.2)
 485 '''''''''''''''''''''''''''''''''''''''''''''''
 486
 487 ``--blacklist`` has been replaced by ``--block-rpcs`` (which is a better
 488 wording for what this option does). The short form ``-b`` still stays
 489 the same and thus is the preferred way for scripts that should run with
 490 both, older and future versions of QEMU.
 491
 492 ``blacklist`` config file option (since 7.2)
 493 ''''''''''''''''''''''''''''''''''''''''''''
 494
 495 The ``blacklist`` config file option has been renamed to ``block-rpcs``
 496 (to be in sync with the renaming of the corresponding command line
 497 option).
 498
 499 Migration
 500 ---------
 501
 502 ``fd:`` URI when used for file migration (since 9.1)
 503 ''''''''''''''''''''''''''''''''''''''''''''''''''''
 504
 505 The ``fd:`` URI can currently provide a file descriptor that
 506 references either a socket or a plain file. These are two different
 507 types of migration. In order to reduce ambiguity, the ``fd:`` URI
 508 usage of providing a file descriptor to a plain file has been
 509 deprecated in favor of explicitly using the ``file:`` URI with the
 510 file descriptor being passed as an ``fdset``. Refer to the ``add-fd``
 511 command documentation for details on the ``fdset`` usage.