---
- branch: MAIN
  date: Mon Mar 28 12:39:10 UTC 2022
  files:
  - new: '1.44'
    old: '1.43'
    path: src/sys/kern/subr_devsw.c
    pathrev: src/sys/kern/subr_devsw.c@1.44
    type: modified
  - new: '1.210'
    old: '1.209'
    path: src/sys/miscfs/specfs/spec_vnops.c
    pathrev: src/sys/miscfs/specfs/spec_vnops.c@1.210
    type: modified
  - new: '1.160'
    old: '1.159'
    path: src/sys/sys/conf.h
    pathrev: src/sys/sys/conf.h@1.160
    type: modified
  id: 20220328T123910Z.f2b8bff9e3a3952ca2deb56367e5a17ea2f9f679
  log: |
    driver(9): New devsw d_cancel op to interrupt I/O before close.

    If specified, when revoking a device node or closing its last open
    node, specfs will:

    1. Call d_cancel, which should return promptly without blocking.
    2. Wait for all concurrent d_read/write/ioctl/&c. to drain.
    3. Call d_close.

    Otherwise, specfs will:

    1. Call d_close.
    2. Wait for all concurrent d_read/write/ioctl/&c. to drain.

    This fallback is problematic because often parts of d_close rely on
    concurrent devsw operations to have completed already, so it is up to
    each driver to have its own mechanism for waiting, and the extra step
    in (2) is almost redundant.  But it is still important to ensure that
    devsw operations are not active by the time a module tries to invoke
    devsw_detach, because only d_open is protected against that.

    The signature of d_cancel matches d_close, mostly so we don't raise
    questions about `why is this different?'; the lwp argument is not
    useful but we should remove it from open/cancel/close all at the same
    time.

    The only way d_cancel should fail, if it does at all, is with ENODEV,
    meaning the driver doesn't support cancelling outstanding I/O, and
    will take responsibility for that in d_close.  I would make it return
    void and only have bdev_cancel and cdev_cancel possibly return ENODEV
    so specfs can detect whether a driver supports it, but this would
    break the pattern around devsw operation types.

    Drivers are allowed to omit it from struct bdevsw, struct cdevsw --
    if so, it is as if they used a function that just returns ENODEV.

    XXX kernel ABI change to struct bdevsw/cdevsw requires bump
  module: src
  subject: 'CVS commit: src/sys'
  unixtime: '1648471150'
  user: riastradh