In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
Using a enum is all nice and generic, but at this point it seems unlikely that
we'll add further build modes. But having an enum means that we need to include
the header file with the enumeration whenerever the conditional is used. I want
to use the conditional in log.h, which makes it hard to avoid circular imports.
Follow-up for 7117842657.
sd_device_monitor_filter_add_match_subsystem_devtype() now returns 1 to signify
that something was done, and 0 to signify that nothing was done, but
udev_monitor_filter_add_match_subsystem_devtype() needs to return 0 as documented.
udev_monitor_filter_add_match_tag() is adjusted to match.
This makes gdm start successfully here again.
Before, it would just not boot, with nothing very obvious in the logs:
gdm[1756]: Gdm: GdmDisplay: Session never registered, failing
Replaces #19171.
Coverity was complaining that we don't check the return value, which we stopped
doing in 772e0a76f3.
But it seems that we don't want those calls at all. The test was originally
added with the call in a6ee01caf3, but I don't
see why we should override this. If the user wants to execute the test with
mempool disabled, we shouldn't ignore that.
Coverity CID#1444464, CID#1444466.
To make sd-device properly usable for all programs we need to provide an
API for the "action" field of an event, it's one of the most relevant
ones, and it was so far missing.
This also adds sd_device_get_seqnum(), which isn't that interesting,
except for generating pretty debug output, which we use it ourselves
for.
This also makes device_new_from_stat_rdev() public, as it is truly
useful, as we can see in our own uses of it, and I think is fairly
generic to show up in the public APIs.
Otherwise, the list becomes dirty when an entry is freed.
This also remove the entry from the hashmap only when its name is set.
The name should be always set, so that does not change anything. But
just for safety.
This should not change anything. As hashmap_remove() is called before
hashmap_ensure_put(). So, even if hashmap_ensure_put() fails, a wrong
entry will not removed from the hashmap by udev_list_entry_free().
But anyway, just for safety.
https://tools.ietf.org/html/draft-knodel-terminology-02https://lwn.net/Articles/823224/
This gets rid of most but not occasions of these loaded terms:
1. scsi_id and friends are something that is supposed to be removed from
our tree (see #7594)
2. The test suite defines an API used by the ubuntu CI. We can remove
this too later, but this needs to be done in sync with the ubuntu CI.
3. In some cases the terms are part of APIs we call or where we expose
concepts the kernel names the way it names them. (In particular all
remaining uses of the word "slave" in our codebase are like this,
it's used by the POSIX PTY layer, by the network subsystem, the mount
API and the block device subsystem). Getting rid of the term in these
contexts would mean doing some major fixes of the kernel ABI first.
Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
Prompted by the discussion on #16110, let's migrate more code to
fd_wait_for_event().
This only leaves 7 places where we call into poll()/poll() directly in
our entire codebase. (one of which is fd_wait_for_event() itself)
poll() sets POLLNVAL inside of the poll structures if an invalid fd is
passed. So far we generally didn't check for that, thus not taking
notice of the error. Given that this specific kind of error is generally
indication of a programming error, and given that our code is embedded
into our projects via NSS or because people link against our library,
let's explicitly check for this and convert it to EBADF.
(I ran into a busy loop because of this missing check when some of my
test code accidentally closed an fd it shouldn't close, so this is a
real thing)
When sd_device_enumerator_add_match_parent() is called
multiple times, then previously set parents are discarded.
This adds device_enumerator_add_match_parent_incremental() to make
sd-device-enumerator scan devices under all specified parents.
Note that for backward compatibility, sd_device_enumerator_add_match_parent()
and udev_enumerate_add_match_parent() still discard previous assignments.
