Portál AbcLinuxu, 10. června 2025 11:56
Řešení dotazu:
29.7.2018 00:43
k3dAR | skóre: 63
cp /dev/sr0 /adresar/soubor.isodale v ("virtualnim") adresari /proc jsou (nejen) procesy jako soubory...
cat /proc/cmdlinezobrazeni informaci o CPU:
cat /proc/cpuinfozobraznei informaci o RAM:
cat /proc/meminfo
echo 5 | sudo tee /sys/class/backlight/acpi_video0/brightnesszjisteni ("cisla") maximalniho podsviceni:
cat /sys/class/backlight/acpi_video0/max_brightnessaktualniho podsviceni:
cat /sys/class/backlight/acpi_video0/actual_brightnesslze nastavovat nektere parametry treba i graficke karty, u AMD muzes pre/pod-taktovat gpu, ram...
29.7.2018 01:46
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
cat /sys/class/backlight/*/*_brightnestzobrazi ti to hodnoty vsech pripadnejch ovladac pro actual a max, pokud by to nebylo stejne (mysleno vzdy ten par) tak zkus nastavit rucne...
.
Ale jinak to je dost přesný, skoro všechno se dá ovládat přes otevřený file deskriptor. Otázka je zda jde všechno číst třeba v shellu, to ne, věci jako memmapped a ioctl se nedají v shellu příliš použít.
Síťování není explicitně soubor, ale se sockety pracuje s file deskriptory a normálně s read/write.
Ale socket nevytvoris cez (f)write, musis ist cez socket().
Obyčejný soubor syscallem write() nevytvořím také. A jestli myslíte open() (nebo creat()), tak tím stejně nevytvořím třeba rouru, znakové nebo blokové zařízení. A jestli narážíte na to, že nemají odpovídající položku ve filesystému, tak zkuste říct, jestli je opravdu tak zásadní rozdíl mezi deskriptory, které vytvoří pipe(), a deskriptory, které vytvoří socketpair().
Není nakonec to "všechno je soubor kromě sítě" stejně prázdná fráze jako původní "všechno je soubor"?
Pravidlo modularity: Pište jednoduché části, které budou spojeny bezchybným rozhraním.O souborech můžeš přemýšlet jako o jednoduchém rozhraní. Pokud chceš zpřístupnit nějaké informace třeba z jádra, můžeš to udělat různými způsoby. Jednou z možností by bylo vytvořit ABI (jako třeba Windows API). Tam může být výhodou snadné použití, ale na druhou stranu jsi odkázaný na jazyk, pro který existují bindingy nebo wrapper. Druhou možností je ty data prostě zpřístupnit jako soubor ve speciálním souborovém systému. Nemusí se tedy nutně jednat o soubory uložené na blokovém zařízení, ale spíš o určitý pohled (view) na data v paměti, nebo rozhraní, které je realizované jako souborový systém. Příkladem budiž procfs a devfs. Dále možná víš, že v UNIX-like systémech existuje adresář /, neboli kořenový adresář (pozor: kořenovým adresářem může být v jiných kontextech myšleno něco jiného). Do jednotlivých adresářů a podadresářů je možné připojovat (tzv. mountovat) jiné souborové systémy. V praxi si to představ jako jeden obrovský strom, jehož kořenem je ten adresář / (a jehož obsah odpovídá tomu, co je uloženo v tvém kořenovém filesystému). Jednotlivé podadresáře se ale můžou chovat jako přístupové body do jiných souborových systémů (ať už fyzických, nebo virtuálních). Kernel pak samozřejmě ví, na kterém fyzickém zařízení – pokud nějakém – ta data skutečně leží. Pro fyzická bloková zařízení lze k zobrazení mapování použít třeba program
lsblk.
Tento návrh má nějaké velmi pěkné vlastnosti. Tím, že u souborů už jsou vyřešena přístupová práva, získáš bez dalšího úsílí nezbytný bezpečnostní mechanismus včetně možnosti konfigurace (přinejmenším někde; nejsem si úplně jistý, že třeba /dev/mem lze zpřístupnit běžnému uživateli). Současně získáš rozhraní, které je strukturované a je možné se v něm orientovat a pracovat s ním pomocí běžných nástrojů. Nevýhodou naopak je nutnost někdy výstup dodatečně parsovat (např. /proc/cpuinfo) a dále si nejsem jistý, jestli někde nemůže být problém s konkurenčním přístupem.
Co se týká toho, co vše je zpřístupněno jako soubor, se tu už rozepsali jiní.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.