Byla vydána verze 9.1 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
Microsoft představil Azure Cobalt 200, tj. svůj vlastní SoC (System-on-Chip) postavený na ARM a optimalizovaný pro cloud.
Co způsobilo včerejší nejhorší výpadek Cloudflare od roku 2019? Nebyl to kybernetický útok. Vše začalo změnou oprávnění v jednom z databázových systémů a pokračovalo vygenerováním problém způsobujícího konfiguračního souboru a jeho distribucí na všechny počítače Cloudflare. Podrobně v příspěvku na blogu Cloudflare.
Byla vydána (Mastodon, 𝕏) první RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Eugen Rochko, zakladatel Mastodonu, tj. sociální sítě, která není na prodej, oznámil, že po téměř 10 letech odstupuje z pozice CEO a převádí vlastnictví ochranné známky a dalších aktiv na neziskovou organizaci Mastodon.
Byla vydána nová major verze 5.0 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v obsáhlých poznámkách k vydání. Videopředstavení na YouTube.
Cloudflare, tj. společnost poskytující "cloudové služby, které zajišťují bezpečnost, výkon a spolehlivost internetových aplikací", má výpadek.
Letos se uskuteční již 11. ročník soutěže v programování Kasiopea. Tato soutěž, (primárně) pro středoškoláky, nabízí skvělou příležitost procvičit logické myšlení a dozvědět se něco nového ze světa algoritmů – a to nejen pro zkušené programátory, ale i pro úplné začátečníky. Domácí kolo proběhne online od 22. 11. do 7. 12. 2025 a skládá se z 9 zajímavých úloh různé obtížnosti. Na výběru programovacího jazyka přitom nezáleží – úlohy jsou
… více »Byla vydána nová verze 2.52.0 distribuovaného systému správy verzí Git. Přispělo 94 vývojářů, z toho 33 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Kdokoliv strávil nějakou dobu studiem specifikace Video4Linux2 API, si určitě všiml, že V4L2 velmi využívá rozhraní ioctl(). Video hardware se - snad nejvíce ze všech druhů periferií - vyznačuje velkým množství možných nastavení. Video streamy mívají velmi mnoho parametrů a často je značná část zpracování prováděna v hardwaru. Snahy o provozování video hardwaru jinak než v běžných, dobře podporovaných režimech mohou vést ke slabému výkonu a často také k žádnému výkonu. Takže není jiné možnosti, než koncové aplikaci zpřístupnit všechny funkce a manýry hardwaru.
Video ovladače tradičně obsahují ioctl() funkce přibližně stejně dlouhé jako romány Neala Stephensona; ačkoliv ty funkce obyčejně dospějí k uspokojivějším závěrům než zmíněné romány, mají tendenci být uprostřed dost rozvláčné. Takže V4L2 API bylo v jádře 2.6.18 změněno; nekonečná funkce ioctl() byla nahrazena velkou sadou zpětných volání, která implementují jednotlivé funkce ioctl(). V 2.6.19-rc3 jich je 79. Naštěstí je většina ovladačů nemusí všechny implementovat.
Ve skutečnosti byla ta dlouhá ioctl() funkce přesunuta do drivers/media/video/videodev.c. To je kód, který se stará o přenos dat mezi uživatelským prostorem a jádrem, a odesílá ovladači jednotlivá ioctl() volání. Aby ho mohl využívat, musí ovladač jako svou ioctl() metodu ve struktuře video_device používat video_ioctl2(). Nakonec by to však většina ovladačů měla mít možnost používat jako unlocked_ioctl(); zamykání v rámci vrstvy Video4Linux2 si s tím umí poradit a ovladače by měly mít řádné zamykání také ošetřeny.
První zpětné volání, které bude váš ovladač pravděpodobně implementovat, je:
int (*vidioc_querycap)(struct file *file, void *priv,
struct v4l2_capability *cap);
Tato funkce se stará o VIDIOC_QUERYCAP ioctl(), tj. pokládá jednoduchou otázku: "co jsi zač a co umíš?" Implementace je u V4L2 ovladačů povinná. V této funkci je, stejně jako u všech ostatních zpětných volání V4L2, parametr priv stejný jako obsah pole file->private_data; běžná praxe je nasměrovat ho na interní strukturu ovladače, která reprezentuje zařízení při open().
Ovladač by měl reagovat vyplněním struktury cap a vrácením běžné hodnoty: nula nebo záporný chybový kód. Při úspěšné návratové hodnotě se V4L2 vrstva postará o zkopírování reakce zpět do uživatelského prostředí.
Struktura v4l2_capability (definovaná v <linux/videodev2.h>) vypadá takto:
struct v4l2_capability
{
__u8 driver[16]; /* např. "bttv" */
__u8 card[32]; /* např. "Hauppauge WinTV" */
__u8 bus_info[32]; /* "PCI:" + pci_name(pci_dev) */
__u32 version; /* měla by se použít KERNEL_VERSION() */
__u32 capabilities; /* schopnosti zařízení */
__u32 reserved[4];
};
Pole driverby mělo být vyplněno názvem ovladače zařízení, zatímco pole card by mělo obsahovat popis hardwaru skrývajícího se za daným zařízením. Ne všechny ovladače se obtěžují vyplňovat pole bus_info; ty, které se obtěžují, obyčejně provedou něco jako:
sprintf(cap->bus_info, "PCI:%s", pci_name(&my_dev));
Pole version značí číslo verze ovladače a pole capabilities je bitmask popisující, co všechno ovladač umí:
Poslední pole (reserved) by mělo být ponecháno na pokoji. Specifikace V4L2 vyžaduje, aby bylo reserved nastaveno na nulu, ale protože video_ioctl2() nastavuje na nulu celou strukturu, je o to už hezky postaráno.
Typickou implementaci najdete v ovladači "vivi":
static int vidioc_querycap (struct file *file, void *priv,
struct v4l2_capability *cap)
{
strcpy(cap->driver, "vivi");
strcpy(cap->card, "vivi");
cap->version = VIVI_VERSION;
cap->capabilities = V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
return 0;
}
Vzhledem k přítomnosti tohoto volání by člověk očekával, že ho aplikace budou používat, a vyhnou se tomu, aby po konkrétních zařízeních žádaly provedení funkcí, kterých nejsou schopna. Z mých dosavadních zkušeností však vyplývá, že aplikace si volání VIDIOC_QUERYCAP příliš nevšímají.
Další volitelné - a ne příliš často implementované - zpětné volání je:
int (*vidioc_log_status) (struct file *file, void *priv);
Tato funkce implementuje VIDIOC_LOG_STATUS a je myšlena jako debugovací pomůcka pro autory video aplikací. Při zavolání by měla vypsat informace o aktuálním stavu ovladače a příslušného hardwaru. Měly by to být dostatečně podrobné informace na to, aby pomohly zmatenému vývojáři aplikace zjistit, proč je video displej prázdný. Jonathan Corbet však doporučuje účinky mírnit voláním printk_ratelimit(), aby se při použití nezpomaloval systém a logy nezaplňovaly smetím.
V další části se podíváme na zbývajících 77 zpětných volání. Především se začneme zabývat dlouhým procesem stanovení sady provozních režimů hardwaru.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Ikdyž nechápu jakou to bude mít pro tebe informační hodnotu?