Jaderné noviny – 10. 4. 2014: Co bude nového v Linuxu 3.15 (diskuse)

[ebik]

Čemu že to flag RENAME_NOREPLACE funkce rename_at2 zabraňuje? Hádám, že to má být naopak (zabraňuje nahrazení při přejmenování).

[Jardík]

To samé se nyní nachází v sysfs pod /sys/firmware/devicetree/base, kam nyní /proc/device-tree odkazuje

Opravdu? A když sysfs budu mít připojený jinde než v /sys (což je naprosto validní případ), tak budu mít neplatný symlink? Nebo bude device-tree magický link, který bude směrovat tam, kam připojím sysfs? Nebo je novinkou, že mi linux neumožní připojit sysfs jinam než do /sys/?

[pavlix]

což je naprosto validní případ

Argumenty? Jestliže nebudeš mít sysfs tam, kde ho hledají aplikace, tak to může být celkem jedno, kam ten symlink odkazuje, ne? :)

[Jardík]

Aplikace ho tam vůbec nemají co hledat. Aplikace se má dotázat "Je připojený sysfs? Pokud ano, kde je připojený?". Třeba formou nějakého systémového volání. Jakého? Nemám páru. Přečtení /proc/self/mountinfo nepřipadá v úvahu, protože procfs taky nemusí být připojen, nebo nemusí být připojen do /proc. Bohužel dnešní linuxový ekosystém je plný aplikací-šmejďáren, co mají hardcódované cesty a různé předpoklady o připojených fs, předpoklady o umístění souborů (příkladem budiž různé shebangy ve skriptech s hardcódovanou cestou pro tu jednu vyvolenou linuxovou distribuci a předpokladem, že vše ostatní je špatně). Částečně je to i chyba linuxového kernelu, protože neexistuje způsob zjistění připojených souborových systémů bez připojeného procfs, které nemůžu najít, kde je připojen, protože na to nemám fcu/syscall. Např. v mé distribuci (JardíkLinux Ultra Super Duper 2014.04.28) mám procfs připojený v /system/proc a sysfs v /system/sys, devfs v /system/dev, ... a všechny ty skripty a aplikace jsou rozbitý a musejí se patchovat, protože pořád něco předpokládají.

[MalyZelenyHnus]

Aplikace ho tam musi hledat - bohuzel. Je to oficialni API sysfs.

linux-3.14.0/Documentation/sysfs-rules.txt

 30 - sysfs is always at /sys
 31   Parsing /proc/mounts is a waste of time. Other mount points are a
 32   system configuration bug you should not try to solve. For test cases,
 33   possibly support a SYSFS_PATH environment variable to overwrite the
 34   application's behavior, but never try to search for sysfs. Never try
 35   to mount it, if you are not an early boot script.

[Jardík]

Ok, beru to, jsem hňup, který to netušil. Je tam to samé pro procfs i devfs?

[werwerwer]

Ked som to pred ~2 rokmi hladal, tak bolo spomenute, ze sysfs musi byt vzdy v /sys a inak je to chyba (aj ked ho je mozne rucne namountovat zaroven inde), procfs je typicky v /proc, na ziadnej rozumnej platforme to nebude inde, ale nemam sa na to spoliehat.

[pavlix]

aj ked ho je mozne rucne namountovat zaroven inde

Ale to má reálné využití pokud vím (jen) v případě, že mountuješ na /nejaka/cesta/sys a plánuješ používat chroot /nejaka/cesta nebo podobnou techniku. Samozřejmě by se to dalo obejít pomocí mount --bind.

procfs je typicky v /proc, na ziadnej rozumnej platforme to nebude inde, ale nemam sa na to spoliehat.

Já osobně bych se nebál spoléhat na to, že pokud je daný filesystém namountovaný, pak je namountovaný v obvyklém místě. Pokud namountovaný není, pak nemusí být daná funkcionalita dostupná a program by měl alespoň ohlásit chybu.

[Michal Kubeček]

Zajímavé je, že zrovna udev pro tento účel má (nebo aspoň míval) template %S ($sys).

[ebik]

Zrovna udev musí být připraven na různé zběsilosti v initrd, kde před voláním pivotroot může být všechno jinak.

[petr_p]

Už to vidím zcela živě:

Automount devtmpfs at /dev, after the kernel mounted the rootfs (DEVTMPFS_MOUNT) [Y/n/?] y
Automount proc at /proc, after the kernel mounted the rootfs (PROC_FS_MOUNT) [Y/n/?] (NEW) y
Automount sysfs at /sys, after the kernel moutner the rootfs (SYSFS_MOUNT) [Y/n/?] (NEW) ?

Mount sysfs to /sys VFS path on root filesystem mount automatically.
Set Yes, if you don't know what you are doing.

Depends on: SYSFS [=y]

[JZD]

s/mapříklad/například/