hope not tied to SystemD
hope not tied to SystemD
Posted Aug 16, 2025 14:28 UTC (Sat) by pizza (subscriber, #46)In reply to: hope not tied to SystemD by Wol
Parent article: Finding a successor to the FHS
The thing is, systemd-udev is literally the canonical udev implementation. Every other has to behave the same way or $badness happens.
So sure, I guess they could cut-and-paste the systemd-udevd documentation and do a global search-and-replace of the name with "the implementation". Or maybe just incorporate it via reference.
Posted Aug 17, 2025 1:07 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Currently, this section of the standard reads as follows:
> /dev/
Frankly, this is basically fine. As I said, the mention of systemd is incidental and not really relevant to application developers anyway.
But if "basically fine" is not good enough, and if we insist on making it perfect, you could argue for changing it to the following:
> /dev/
Maybe also add a paragraph like this:
> The userspace component responsible for managing this directory is considered an implementation detail. Portable applications should not make assumptions about the nature or behavior of said component, unless the application takes a dependency on systemd or some other specific implementation.
But there is absolutely no need to go into exhaustive detail of exactly how systemd happens to do this. What matters is that:
1. Device files live in /dev/.
Posted Aug 25, 2025 16:32 UTC (Mon)
by pj (subscriber, #4506)
[Link]
hope not tied to SystemD
>
> The root directory for device nodes. Usually, this directory is mounted as a devtmpfs instance, but might be of a different type in sandboxed/containerized setups. This directory is managed jointly by the kernel and systemd-udevd(8), and should not be written to by other components. A number of special purpose virtual file systems might be mounted below this directory.
>
> The root directory for device nodes. Usually, this directory is mounted as a devtmpfs instance, but might be of a different type in sandboxed/containerized setups. This directory is managed jointly by the kernel and a userspace component such as systemd-udevd(8), and should not be written to by other components. A number of special purpose virtual file systems might be mounted below this directory.
2. The host environment or "operating system," broadly construed, is responsible for managing those device files.
3. If you're an application developer, this is not your problem to deal with. Don't try to do anything clever, just open the device file you want to use.
4. ...unless you're willing to take a systemd dependency, then of course you can assume systemd-specific behaviors.
hope not tied to SystemD