/devist eine tmpfs-Variante (devtmpfs). Der Kernel füllt ihn mit Geräteknoten auf, der Inhalt ist jedoch flexibel, und der udev- Userspace-Daemon passt seine Berechtigungen an, erstellt Symlinks (z. B. / dev / disk / by- *) usw.
Sie möchten die vorhandene Instanz binden, um die von udev vorgenommenen Änderungen zu übernehmen. Wenn Sie versuchen, eine neue Instanz zu mounten, erhalten Sie neue tmpfs mit nur vom Kernel bereitgestellten Knoten, aber ohne udev-Links.Scratch, dass anscheinend die aktuellen Kernel tun devtmpfs als Single-Instance behandeln, als zu gewöhnlichen tmpfs gegenüber . Das heißt, wenn Sie es zweimal installieren, erhalten Sie beide Male denselben Inhalt.
Ich denke jedoch, dass die gleiche Argumentation immer noch gilt: Die Leute empfehlen binding / dev, weil sie die gleiche Annahme machen, die ich gemacht habe (ob richtig oder nicht), dass es genauso funktioniert wie ein herkömmliches TMPPS.
Darüber hinaus bis vor kurzem / dev war in der Tat ein traditionelles tmpfs mit allem drin von User - Space (udev oder ähnlichem) erstellt. Beim Arbeiten mit Systemen vor dem Hinzufügen von devtmpfs war das Binden von / dev immer noch eine Notwendigkeit.
/procund /syssind vollständig virtuelle Dateisysteme (procfs und sysfs). Der Kern steuert alle Operationen und definiert eine starre Struktur.
Mehrere procfs- oder sysfs-Mounts innerhalb desselben Namespaces sind vollständig identisch - alle beziehen sich auf dieselbe Instanz des Dateisystems. Daher besteht kein Unterschied zwischen dem Einrichten einer neuen Instanz für eine gewöhnliche Chroot und dem Binden einer vorhandenen Instanz.
(Unterschiede treten bei der Arbeit mit Containern auf, z. B. Prozess-Namespaces oder Netzwerk-Namespaces.) Das Mounten einer neuen procfs-Instanz in einem Container würde nur eine eingeschränkte Sicht auf die eigenen Prozesse geben. Durch die Bindung der procfs des Hosts würde der Container alle Prozesse sehen. )