Two board kernel configs disable inotify outright, along with fanotify:
br-ext-chip-ingenic/board/t40/t40.generic.config:1805-1806br-ext-chip-allwinner/board/v83x/v83x.generic.config:2572-2573
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
Affected defconfigs: t40_lite, t40_ultimate, v83x_lite, v83x_ultimate.
Why this looks unintentional
INOTIFY_USER is default y upstream, and every other board in the tree agrees with that:
| state |
count |
CONFIG_INOTIFY_USER=y |
71 |
symbol absent (short .neo seed fragment, inherits default y) |
6 |
explicitly is not set |
2 |
The six that omit the symbol are ~230-line seed fragments, not full configs, so they are fine.
The two that turn it off are full generated configs (2320 and 3140 lines), so the negation is
almost certainly inherited from a vendor defconfig that was trimmed for size rather than a
decision anyone made about OpenIPC.
Why it matters
No in-tree consumer needs inotify today, which is why this has gone unnoticed. But it
silently removes a whole class of userspace capability on those four images — any daemon or
tool that wants to watch a file for changes simply cannot, and the failure mode is a
inotify_init1() returning ENOSYS at runtime rather than anything visible at build time.
The concrete case that prompted this: we are looking at having majestic watch
/etc/majestic.yaml so an edit applies without a reload. On t40 and v83x that watch could
never be established, so the feature would have to degrade to SIGHUP-only on exactly these
boards while working everywhere else — a per-board behavioural split with no reason behind it.
Asks
- Confirm whether the negation is deliberate, and measure what turning it back on costs in
kernel size on each of the two boards.
- If the cost is small, set
CONFIG_INOTIFY_USER=y for consistency with the other 71.
- If the cost is real and the boards are tight, record the exception somewhere a future
author will find it, so the next feature that wants a file watch knows to degrade rather
than assume.
Not urgent — filing so it is written down before it bites something.
Two board kernel configs disable inotify outright, along with fanotify:
br-ext-chip-ingenic/board/t40/t40.generic.config:1805-1806br-ext-chip-allwinner/board/v83x/v83x.generic.config:2572-2573Affected defconfigs:
t40_lite,t40_ultimate,v83x_lite,v83x_ultimate.Why this looks unintentional
INOTIFY_USERisdefault yupstream, and every other board in the tree agrees with that:CONFIG_INOTIFY_USER=y.neoseed fragment, inheritsdefault y)is not setThe six that omit the symbol are ~230-line seed fragments, not full configs, so they are fine.
The two that turn it off are full generated configs (2320 and 3140 lines), so the negation is
almost certainly inherited from a vendor defconfig that was trimmed for size rather than a
decision anyone made about OpenIPC.
Why it matters
No in-tree consumer needs inotify today, which is why this has gone unnoticed. But it
silently removes a whole class of userspace capability on those four images — any daemon or
tool that wants to watch a file for changes simply cannot, and the failure mode is a
inotify_init1()returningENOSYSat runtime rather than anything visible at build time.The concrete case that prompted this: we are looking at having majestic watch
/etc/majestic.yamlso an edit applies without a reload. On t40 and v83x that watch couldnever be established, so the feature would have to degrade to SIGHUP-only on exactly these
boards while working everywhere else — a per-board behavioural split with no reason behind it.
Asks
kernel size on each of the two boards.
CONFIG_INOTIFY_USER=yfor consistency with the other 71.author will find it, so the next feature that wants a file watch knows to degrade rather
than assume.
Not urgent — filing so it is written down before it bites something.