mirror of
https://git.proxmox.com/git/systemd
synced 2025-10-04 19:54:47 +00:00
New upstream version 240
This commit is contained in:
Michael Biebl
parent
b012e92123
commit
6e866b331d
@ -2,17 +2,14 @@
|
||||
; A list of (major-mode . ((var1 . value1) (var2 . value2)))
|
||||
; Mode can be nil, which gives default values.
|
||||
|
||||
; Note that we set a line width of 119 for .c and XML files, but for everything
|
||||
; Note that we set a line width of 109 for .c and XML files, but for everything
|
||||
; else (such as journal catalog files, unit files, README files) we stick to a
|
||||
; more conservative 79 characters.
|
||||
|
||||
; NOTE: If you update this file make sure to update .vimrc and .editorconfig,
|
||||
; too.
|
||||
|
||||
((nil . ((indent-tabs-mode . nil)
|
||||
(tab-width . 8)
|
||||
(fill-column . 79)))
|
||||
(c-mode . ((fill-column . 119)
|
||||
((c-mode . ((fill-column . 109)
|
||||
(c-basic-offset . 8)
|
||||
(eval . (c-set-offset 'substatement-open 0))
|
||||
(eval . (c-set-offset 'statement-case-open 0))
|
||||
@ -20,8 +17,11 @@
|
||||
(eval . (c-set-offset 'arglist-intro '++))
|
||||
(eval . (c-set-offset 'arglist-close 0))))
|
||||
(nxml-mode . ((nxml-child-indent . 2)
|
||||
(fill-column . 119)))
|
||||
(fill-column . 109)))
|
||||
(meson-mode . ((meson-indent-basic . 8)))
|
||||
(sh-mode . ((sh-basic-offset . 8)
|
||||
(sh-indentation . 8)))
|
||||
(awk-mode . ((c-basic-offset . 8))))
|
||||
(awk-mode . ((c-basic-offset . 8)))
|
||||
(nil . ((indent-tabs-mode . nil)
|
||||
(tab-width . 8)
|
||||
(fill-column . 79))) )
|
||||
|
||||
2
.github/ISSUE_TEMPLATE/Bug_report.md
vendored
2
.github/ISSUE_TEMPLATE/Bug_report.md
vendored
@ -8,7 +8,7 @@ about: A report of an error in a recent systemd version
|
||||
> ...
|
||||
|
||||
<!-- **NOTE:** Do not submit bug reports about anything but the two most recently released systemd versions upstream! -->
|
||||
<!-- For older version please use distribution trackers (see https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md#filing-issues). -->
|
||||
<!-- For older version please use distribution trackers (see https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md#filing-issues). -->
|
||||
|
||||
**Used distribution**
|
||||
> …
|
||||
|
||||
3
.gitignore
vendored
3
.gitignore
vendored
@ -10,6 +10,7 @@
|
||||
*.trs
|
||||
*~
|
||||
.config.args
|
||||
.gdb_history
|
||||
.deps/
|
||||
/*.gcda
|
||||
/*.gcno
|
||||
@ -25,9 +26,11 @@
|
||||
/build*
|
||||
/coverage/
|
||||
/image.raw
|
||||
/.#image.raw.lck
|
||||
/image.raw.cache-pre-dev
|
||||
/image.raw.cache-pre-inst
|
||||
/install-tree
|
||||
/.mkosi-*
|
||||
/mkosi.builddir/
|
||||
/mkosi.output/
|
||||
/tags
|
||||
|
||||
13
.lgtm.yml
Normal file
13
.lgtm.yml
Normal file
@ -0,0 +1,13 @@
|
||||
extraction:
|
||||
cpp:
|
||||
prepare:
|
||||
packages:
|
||||
- python3-pip
|
||||
- python3-setuptools
|
||||
- python3-wheel
|
||||
after_prepare:
|
||||
- pip3 install meson
|
||||
- export PATH="$HOME/.local/bin/:$PATH"
|
||||
python:
|
||||
python_setup:
|
||||
version: 3
|
||||
21
.lgtm/cpp-queries/fgets.ql
Normal file
21
.lgtm/cpp-queries/fgets.ql
Normal file
@ -0,0 +1,21 @@
|
||||
/**
|
||||
* @name Use of fgets()
|
||||
* @description fgets() is dangerous to call. Use read_line() instead.
|
||||
* @kind problem
|
||||
* @problem.severity error
|
||||
* @precision high
|
||||
* @id cpp/fgets
|
||||
* @tags reliability
|
||||
* security
|
||||
*/
|
||||
import cpp
|
||||
|
||||
predicate dangerousFunction(Function function) {
|
||||
exists (string name | name = function.getQualifiedName() |
|
||||
name = "fgets")
|
||||
}
|
||||
|
||||
from FunctionCall call, Function target
|
||||
where call.getTarget() = target
|
||||
and dangerousFunction(target)
|
||||
select call, target.getQualifiedName() + " is potentially dangerous"
|
||||
323
.mailmap
323
.mailmap
@ -1,163 +1,194 @@
|
||||
Kay Sievers <kay@vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay.sievers@vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay.sievers@suse.de>
|
||||
Kay Sievers <kay@vrfy.org> <kay@pim.off.vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay@pim>
|
||||
Kay Sievers <kay@vrfy.org> <kay@yik.fritz.box>
|
||||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <greg@kroah.com>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <greg@press.(none)>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <gregkh@suse.de>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <greg@bucket.kroah.org>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <gregkh@linuxfoundation.org>
|
||||
Harald Hoyer <harald@redhat.com>
|
||||
Alan Jenkins <alan.christopher.jenkins@googlemail.com>
|
||||
Alan Jenkins <alan.christopher.jenkins@googlemail.com> <alan-jenkins@tuffmail.co.uk>
|
||||
Alan Robertson <aroberts@zen.iomart.com> <alanjrobertson@gmail.com>
|
||||
Alexander Kochetkov <al.kochet@gmail.com>
|
||||
Alexander Kuleshov <kuleshovmail@gmail.com> <0xAX@users.noreply.github.com>
|
||||
Alexander Kurtz <alexander@kurtz.be>
|
||||
Alexandros Frantzis <alexandros.frantzis@canonical.com>
|
||||
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
|
||||
Ananth N Mavinakayanahalli <ananth@in.ibm.com> <ananthmg@rediffmail.com>
|
||||
Andreas Henriksson <andreas@fatal.se>
|
||||
Anthony Parsons <flussence@users.noreply.github.com>
|
||||
Antoine Eiche <lewo@abesis.fr>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Atul Sabharwal <atul.sabharwal@intel.com>
|
||||
Bart Rulon <barron@lexmark.com>
|
||||
Bastien Nocera <hadess@hadess.net> <hadess@users.noreply.github.com>
|
||||
Beniamino Galvani <bgalvani@redhat.com> <bengal@users.noreply.github.com>
|
||||
Bill Yodlowsky <bill@redhat.com> <itsbill@users.noreply.github.com>
|
||||
Brian Boylston <brian.boylston@hpe.com>
|
||||
Charles (Chas) Williams <ciwillia@brocade.com>
|
||||
Chen Qi <Qi.Chen@windriver.com> <40684930+ChenQi1989@users.noreply.github.com>
|
||||
Christophe Varoqui <christophe.varoqui@free.fr>
|
||||
Colin Guthrie <ColinGuthrie@web>
|
||||
Daniel Elstner <daniel.kitta@gmail.com> <danielk@openismus.com>
|
||||
Daniel J Walsh <dwalsh@redhat.com>
|
||||
Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
||||
Daniel Machon <Danielmachon@live.dk>
|
||||
Daniel Rusek <mail@asciiwolf.com>
|
||||
Daniel Stekloff <dsteklof@us.ibm.com>
|
||||
Daniel Șerbănescu <dasj19@users.noreply.github.com>
|
||||
Dave Reisner <dreisner@archlinux.org> <d@falconindy.com>
|
||||
David Zeuthen <david@fubar.dk>
|
||||
David Zeuthen <david@fubar.dk> <davidz@redhat.com>
|
||||
David Zeuthen <david@fubar.dk> <zeuthen@gmail.com>
|
||||
Hannes Reinecke <hare@suse.de>
|
||||
Scott James Remnant <scott@netsplit.com>
|
||||
Scott James Remnant <scott@netsplit.com> <scott@ubuntu.com>
|
||||
Alan Jenkins <alan.christopher.jenkins@googlemail.com>
|
||||
Alan Jenkins <alan.christopher.jenkins@googlemail.com> <alan-jenkins@tuffmail.co.uk>
|
||||
Marco d'Itri <md@linux.it> <md@Linux.IT>
|
||||
Robert Gerus <ar@bash.org.pl> Robert "arachnist" Gerus <ar@bash.org.pl>
|
||||
Fabiano Fidêncio <fabianofidencio@gmail.com> Fabiano Fidencio <fidencio@profusion.mobi>
|
||||
Martin Pitt <martinpitt@gnome.org>
|
||||
Martin Pitt <martinpitt@gnome.org> <martin.pitt@ubuntu.com>
|
||||
Daniel J Walsh <dwalsh@redhat.com>
|
||||
Dave Reisner <dreisner@archlinux.org> <d@falconindy.com>
|
||||
Diego Elio Pettenò <flameeyes@gmail.com>
|
||||
Daniel Elstner <daniel.kitta@gmail.com> <danielk@openismus.com>
|
||||
Frederic Crozat <fcrozat@suse.com> <fcrozat@mandriva.com>
|
||||
Ian Campbell <ijc@hellion.org.uk> <Ian.Campbell@citrix.com>
|
||||
Jerone Young <jyoung@redhat.com> <jerone.young@canonical.com>
|
||||
Luis Felipe Strano Moraes <luis.strano@gmail.com> <lfelipe@profusion.mobi>
|
||||
Mario Limonciello <mario_limonciello@dell.com> <Mario_Limonciello@dell.com>
|
||||
Matthias Clasen <mclasen@redhat.com> <matthias.clasen@gmail.com>
|
||||
Michal Soltys <soltys@ziu.info> <nozo@ziu.info>
|
||||
Piter PUNK <piterpunk@slackware.com> <piterpk@terra.com.br>
|
||||
Richard Hughes <richard@hughsie.com> <hughsient@gmail.com>
|
||||
Robby Workman <rw@rlworkman.net> <rworkman@slackware.com>
|
||||
Shawn Landden <shawnlandden@gmail.com> <shawn@churchofgit.com>
|
||||
Simon Peeters <peeters.simon@gmail.com>
|
||||
Tobias Klauser <tklauser@distanz.ch> <tklauser@nuerscht.ch>
|
||||
Miklos Vajna <vmiklos@frugalware.org> <vmiklos@gmail.com>
|
||||
William Jon McCann <jmccann@redhat.com> <william.jon.mccann@gmail.com>
|
||||
Yin Kangkai <kangkai.yin@intel.com> <kangkai.yin@linux.intel.com>
|
||||
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
|
||||
Lennart Poettering <lennart@poettering.net> <lennart@bf9bc1cc-28ce-0310-abfb-9041aa761afb>
|
||||
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
|
||||
Ananth N Mavinakayanahalli <ananth@in.ibm.com> <ananthmg@rediffmail.com>
|
||||
Ted Ts'o <tytso@mit.edu>
|
||||
Tobias Klauser <tklauser@access.unizh.ch>
|
||||
Tobias Klauser <tklauser@access.unizh.ch> <tklauser@access.unizh.chbk>
|
||||
Tobias Klauser <tklauser@access.unizh.ch> <klauser@access.unizh.ch>
|
||||
Tobias Klauser <tklauser@access.unizh.ch> <tklauser@distanz.ch>
|
||||
Patrick Mansfield <patmans@us.ibm.com>
|
||||
Christophe Varoqui <christophe.varoqui@free.fr>
|
||||
Daniel Stekloff <dsteklof@us.ibm.com>
|
||||
Michael Buesch <mbuesch@freenet.de>
|
||||
Olaf Hering <olh@suse.de>
|
||||
Robert Love <rml@tech9.net>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Tom Rini <trini@kernel.crashing.org>
|
||||
Paul Mundt <lethal@linux-sh.org>
|
||||
Atul Sabharwal <atul.sabharwal@intel.com>
|
||||
Daniel Machon <Danielmachon@live.dk>
|
||||
Thomas Blume <Thomas.Blume@suse.com>
|
||||
Pablo Lezaeta Reyes <prflr88@gmail.com>
|
||||
Otto Wallenius <otto_026@hotmail.com>
|
||||
Tom Yan <tom.ty89@gmail.com>
|
||||
Marty Plummer <ntzrmtthihu777@gmail.com>
|
||||
Brian Boylston <brian.boylston@hpe.com>
|
||||
Thomas H. P. Andersen <phomes@gmail.com>
|
||||
Michael Olbrich <m.olbrich@pengutronix.de>
|
||||
Douglas Christman <DouglasChristman@gmail.com>
|
||||
Alexander Kuleshov <kuleshovmail@gmail.com> <0xAX@users.noreply.github.com>
|
||||
Andreas Henriksson <andreas@fatal.se>
|
||||
Daniel Rusek <mail@asciiwolf.com>
|
||||
Davide Cavalca <dcavalca@fb.com> <davide125@tiscali.it>
|
||||
Dennis Wassenberg <dennis.wassenberg@secunet.com>
|
||||
Reid Price <reid.price@gmail.com>
|
||||
Stefan Schweter <stefan@schweter.it>
|
||||
Seraphime Kirkovski <kirkseraph@gmail.com>
|
||||
Bart Rulon <barron@lexmark.com>
|
||||
Richard W.M. Jones <rjones@redhat.com>
|
||||
Roman Stingler <coolx67@gmx.at>
|
||||
Michael Hoy <rimmington@gmail.com>
|
||||
Tiago Levit <liamgliam@gmail.com>
|
||||
Diego Elio Pettenò <flameeyes@gmail.com>
|
||||
Dmitriy Geels <dmitriy.geels@gmail.com>
|
||||
Dmitry Khlebnikov <dmitry.khlebnikov@rea-group.com> <galaxy4public@users.noreply.github.com>
|
||||
Douglas Christman <DouglasChristman@gmail.com>
|
||||
Emil Soleyman <emil@soleyman.com>
|
||||
Eric Cook <llua@users.noreply.github.com>
|
||||
Lukáš Nykrýn <lnykryn@redhat.com>
|
||||
Evgeny Vereshchagin <evvers@ya.ru>
|
||||
Fabiano Fidêncio <fabianofidencio@gmail.com> Fabiano Fidencio <fidencio@profusion.mobi>
|
||||
Faizal Luthfi <zalluth@gmail.com>
|
||||
Federico Di Pierro <nierro92@gmail.com>
|
||||
Fionn Cleary <clearyf@tcd.ie>
|
||||
Frederic Crozat <fcrozat@suse.com> <fcrozat@mandriva.com>
|
||||
Gautier Husson <admin_github@liberasys.com>
|
||||
George Gaydarov <git@gg7.io> <gg7@users.noreply.github.com>
|
||||
Gianluca Boiano <morf3089@gmail.com>
|
||||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <greg@bucket.kroah.org>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <greg@kroah.com>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <greg@press.(none)>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <gregkh@linuxfoundation.org>
|
||||
Greg Kroah-Hartman <greg@kroah.com> <gregkh@suse.de>
|
||||
Gwendal Grignou <gwendal@chromium.org>
|
||||
Hannes Reinecke <hare@suse.de>
|
||||
Harald Hoyer <harald@redhat.com>
|
||||
Harald Hoyer <harald@redhat.com> <harald@hoyer.xyz>
|
||||
Heikki Kemppainen <heikki.kemppainen@nokia.com>
|
||||
Hendrik Brueckner <hbrueckner@users.noreply.github.com>
|
||||
Alexandros Frantzis <alexandros.frantzis@canonical.com>
|
||||
Alexander Kochetkov <al.kochet@gmail.com>
|
||||
Fionn Cleary <clearyf@tcd.ie>
|
||||
Michel Kraus <github@demonsphere.de> <27o@users.noreply.github.com>
|
||||
Charles (Chas) Williams <ciwillia@brocade.com>
|
||||
Emil Soleyman <emil@soleyman.com>
|
||||
Dmitry Khlebnikov <dmitry.khlebnikov@rea-group.com> <galaxy4public@users.noreply.github.com>
|
||||
Antoine Eiche <lewo@abesis.fr>
|
||||
Gianluca Boiano <morf3089@gmail.com>
|
||||
Paolo Giangrandi <paolo@luccalug.it>
|
||||
Karl Kraus <karl.kraus@tum.de> <laqueray@gmail.com>
|
||||
Tibor Nagy <xnagytibor@gmail.com>
|
||||
Stuart McLaren <stuart.mclaren@hp.com>
|
||||
Hendrik Westerberg <hendrik@gestorf.com>
|
||||
Ian Campbell <ijc@hellion.org.uk> <Ian.Campbell@citrix.com>
|
||||
Insun Pyo <insun.pyo@samsung.com>
|
||||
Insun Pyo <insun.pyo@samsung.com> <iplayinsun@gmail.com>
|
||||
Jerone Young <jyoung@redhat.com> <jerone.young@canonical.com>
|
||||
Jiuyang Liu <liujiuyang1994@gmail.com>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> <glaubitz@suse.com>
|
||||
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
|
||||
Neil Brown <neil@brown.name>
|
||||
Michal Suchanek <msuchanek@suse.de> <hramrach@gmail.com>
|
||||
Michal Suchanek <msuchanek@suse.de>
|
||||
Bastien Nocera <hadess@hadess.net> <hadess@users.noreply.github.com>
|
||||
Umut Tezduyar Lindskog <umut@tezduyar.com>
|
||||
Alexander Kurtz <alexander@kurtz.be>
|
||||
Piotr Szydełko <wiertel@users.sourceforge.net>
|
||||
Łukasz Stelmach <l.stelmach@samsung.com> <stlman@poczta.fm>
|
||||
Krzysztof Jackiewicz <k.jackiewicz@samsung.com> <kjackiewicz@users.noreply.github.com>
|
||||
Marcus Cooper <marcusc@axis.com> <codekipper@gmail.com>
|
||||
Insun Pyo <insun.pyo@samsung.com> <iplayinsun@gmail.com>
|
||||
Ted Wood <ted.l.wood@gmail.com>
|
||||
Ted Wood <ted@mailchimp.com>
|
||||
Anthony Parsons <flussence@users.noreply.github.com>
|
||||
Federico Di Pierro <nierro92@gmail.com>
|
||||
Jon Ringle <jringle@gridpoint.com> <ringlej@users.noreply.github.com>
|
||||
Jonas Dorel <jonas.dorel@laposte.net>
|
||||
Josef Andersson <josef.andersson@fripost.org>
|
||||
Josef Andersson <l10nl18nsweja@gmail.com>
|
||||
Hendrik Westerberg <hendrik@gestorf.com>
|
||||
Stefan Pietsch <mail.ipv4v6@gmail.com>
|
||||
Jérémy Rosen <jeremy.rosen@enst-bretagne.fr>
|
||||
Vasilis Liaskovitis <vliaskov@gmail.com>
|
||||
Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
||||
Tomasz Pala <gotar@polanet.pl>
|
||||
Dmitriy Geels <dmitriy.geels@gmail.com>
|
||||
Beniamino Galvani <bgalvani@redhat.com> <bengal@users.noreply.github.com>
|
||||
Justin Capella <justincapella@gmail.com> <b1tninja@users.noreply.github.com>
|
||||
Daniel Șerbănescu <dasj19@users.noreply.github.com>
|
||||
Stanislav Angelovič <angelovic.s@gmail.com>
|
||||
Torsten Hilbrich <torsten.hilbrich@gmx.net>
|
||||
Tinu Weber <takeya@bluewin.ch>
|
||||
Gwendal Grignou <gwendal@chromium.org>
|
||||
José Bollo <jose.bollo@iot.bzh> <jobol@nonadev.net>
|
||||
Patryk Kocielnik <longer44@gmail.com>
|
||||
Lukáš Říha <cedel@centrum.cz>
|
||||
Alan Robertson <aroberts@zen.iomart.com> <alanjrobertson@gmail.com>
|
||||
Martin Steuer <martinsteuer@gmx.de>
|
||||
Matthias-Christian Ott <ott@mirix.org> <ott@users.noreply.github.com>
|
||||
Larry Bernstone <lbernstone@gmail.com>
|
||||
Michał Szczepański <skrzatu@hotmail.com> <skrzatu@gmail.com>
|
||||
Tomasz Bachorski <tomasz.bachorski@x7f.io> <34866781+nulsoh@users.noreply.github.com>
|
||||
Zachary Winnerman <33329648+winnerman-pythian@users.noreply.github.com>
|
||||
Vladislav Vishnyakov <split7fire@yandex.ru>
|
||||
Robert Kolchmeyer <rkolchmeyer@google.com> <rkolchmeyer@users.noreply.github.com>
|
||||
George Gaydarov <git@gg7.io> <gg7@users.noreply.github.com>
|
||||
Bill Yodlowsky <bill@redhat.com> <itsbill@users.noreply.github.com>
|
||||
Mao Huang <littlecvr@gmail.com>
|
||||
Pavel Hrdina <phrdina@redhat.com>
|
||||
Jun Bo Bi <jambonmcyeah@gmail.com>
|
||||
Justin Capella <justincapella@gmail.com> <b1tninja@users.noreply.github.com>
|
||||
Jérémy Rosen <jeremy.rosen@enst-bretagne.fr>
|
||||
Jürg Billeter <j@bitron.ch>
|
||||
Karl Kraus <karl.kraus@tum.de> <laqueray@gmail.com>
|
||||
Kay Sievers <kay@vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay.sievers@suse.de>
|
||||
Kay Sievers <kay@vrfy.org> <kay.sievers@vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay@pim.off.vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay@pim>
|
||||
Kay Sievers <kay@vrfy.org> <kay@yik.fritz.box>
|
||||
Krzysztof Jackiewicz <k.jackiewicz@samsung.com> <kjackiewicz@users.noreply.github.com>
|
||||
Larry Bernstone <lbernstone@gmail.com>
|
||||
Lennart Poettering <lennart@poettering.net> <LennartPoettering@web>
|
||||
Lennart Poettering <lennart@poettering.net> <lennart@bf9bc1cc-28ce-0310-abfb-9041aa761afb>
|
||||
Lennart Poettering <lennart@poettering.net> <mzninuv@0pointer.de>
|
||||
Leonard König <leonard.r.koenig@googlemail.com>
|
||||
Luis Felipe Strano Moraes <luis.strano@gmail.com> <lfelipe@profusion.mobi>
|
||||
Lukáš Nykrýn <lnykryn@redhat.com>
|
||||
Lukáš Říha <cedel@centrum.cz>
|
||||
Mao Huang <littlecvr@gmail.com>
|
||||
Marco d'Itri <md@linux.it> <md@Linux.IT>
|
||||
Marcus Cooper <marcusc@axis.com> <codekipper@gmail.com>
|
||||
Mario Limonciello <mario_limonciello@dell.com> <Mario_Limonciello@dell.com>
|
||||
Martin Pitt <martin@piware.de> <martinpitt@users.noreply.github.com>
|
||||
Martin Pitt <martinpitt@gnome.org>
|
||||
Martin Pitt <martinpitt@gnome.org> <martin.pitt@ubuntu.com>
|
||||
Martin Steuer <martinsteuer@gmx.de>
|
||||
Marty Plummer <ntzrmtthihu777@gmail.com>
|
||||
Matthew Leeds <matthew.leeds@endlessm.com> <mwl458@gmail.com>
|
||||
Matthew McGinn <mamcgi@gmail.com> <xginn8@users.noreply.github.com>
|
||||
Matthias Clasen <mclasen@redhat.com> <matthias.clasen@gmail.com>
|
||||
Matthias-Christian Ott <ott@mirix.org> <ott@users.noreply.github.com>
|
||||
Michael Biebl <biebl@debian.org> <mbiebl@gmail.com>
|
||||
Michael Buesch <mbuesch@freenet.de>
|
||||
Michael Hoy <rimmington@gmail.com>
|
||||
Michael Olbrich <m.olbrich@pengutronix.de>
|
||||
Michal Soltys <soltys@ziu.info> <nozo@ziu.info>
|
||||
Michal Suchanek <msuchanek@suse.de>
|
||||
Michal Suchanek <msuchanek@suse.de> <hramrach@gmail.com>
|
||||
Michał Szczepański <skrzatu@hotmail.com> <skrzatu@gmail.com>
|
||||
Michel Kraus <github@demonsphere.de> <27o@users.noreply.github.com>
|
||||
Miklos Vajna <vmiklos@frugalware.org> <vmiklos@gmail.com>
|
||||
Milan Pässler <me@petabyteboy.de>
|
||||
Wim van Mourik <wvanmourik@computest.nl> <githubw@use.startmail.com>
|
||||
Neil Brown <neil@brown.name>
|
||||
Neil Brown <neilb@suse.com>
|
||||
Niklas Tibbling <niklasti@axis.com> <45659916+tibbling@users.noreply.github.com>
|
||||
Nikolas Nyby <nnyby@columbia.edu>
|
||||
Nogisaka Sadata <ngsksdt@gmail.com>
|
||||
Olaf Hering <olh@suse.de>
|
||||
Otto Wallenius <otto_026@hotmail.com>
|
||||
Pablo Lezaeta Reyes <prflr88@gmail.com>
|
||||
Paolo Giangrandi <paolo@luccalug.it>
|
||||
Patrick Mansfield <patmans@us.ibm.com>
|
||||
Patryk Kocielnik <longer44@gmail.com>
|
||||
Paul Mundt <lethal@linux-sh.org>
|
||||
Pavel Hrdina <phrdina@redhat.com>
|
||||
Peter D'Hoye <peter.dhoye@gmail.com>
|
||||
Piotr Szydełko <wiertel@users.sourceforge.net>
|
||||
Piter PUNK <piterpunk@slackware.com> <piterpk@terra.com.br>
|
||||
Reid Price <reid.price@gmail.com>
|
||||
Reinhold Mueller <mueller.reinhold@web.de>
|
||||
Richard Hughes <richard@hughsie.com> <hughsient@gmail.com>
|
||||
Richard W.M. Jones <rjones@redhat.com>
|
||||
Robby Workman <rw@rlworkman.net> <rworkman@slackware.com>
|
||||
Robert Gerus <ar@bash.org.pl> Robert "arachnist" Gerus <ar@bash.org.pl>
|
||||
Robert Kolchmeyer <rkolchmeyer@google.com> <rkolchmeyer@users.noreply.github.com>
|
||||
Robert Love <rml@tech9.net>
|
||||
Roman Stingler <coolx67@gmx.at>
|
||||
Rubén Suárez Alvarez <rubensa@tluportatil082> <rubensa@gmail.com>
|
||||
Salvo Tomaselli <ltworf@users.noreply.github.com>
|
||||
Matthew McGinn <mamcgi@gmail.com> <xginn8@users.noreply.github.com>
|
||||
Evgeny Vereshchagin <evvers@ya.ru>
|
||||
Peter D'Hoye <peter.dhoye@gmail.com>
|
||||
Sandy Carter <bwrsandman@gmail.com>
|
||||
Scott James Remnant <scott@netsplit.com>
|
||||
Scott James Remnant <scott@netsplit.com> <scott@ubuntu.com>
|
||||
Seraphime Kirkovski <kirkseraph@gmail.com>
|
||||
Shawn Landden <shawnlandden@gmail.com> <shawn@churchofgit.com>
|
||||
Shawn Landden <slandden@gmail.com> <shawn@git.icu>
|
||||
Silvio Knizek <killermoehre@gmx.net>
|
||||
Simon Peeters <peeters.simon@gmail.com>
|
||||
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
|
||||
Stanislav Angelovič <angelovic.s@gmail.com>
|
||||
Stasiek Michalski <hellcp@opensuse.org>
|
||||
Stefan Pietsch <mail.ipv4v6@gmail.com>
|
||||
Stefan Schweter <stefan@schweter.it>
|
||||
Stuart McLaren <stuart.mclaren@hp.com>
|
||||
Susant Sahani <ssahani@gmail.com> <145210+ssahani@users.noreply.github.com>
|
||||
Susant Sahani <ssahani@gmail.com> <susant@redhat.com>
|
||||
Sébastien Bacher <seb128@ubuntu.com>
|
||||
Tanu Kaskinen <TanuKaskinen@web>
|
||||
Ted Ts'o <tytso@mit.edu>
|
||||
Ted Wood <ted.l.wood@gmail.com>
|
||||
Ted Wood <ted@mailchimp.com>
|
||||
Thomas Blume <Thomas.Blume@suse.com>
|
||||
Thomas H. P. Andersen <phomes@gmail.com>
|
||||
Tiago Levit <liamgliam@gmail.com>
|
||||
Tibor Nagy <xnagytibor@gmail.com>
|
||||
Tinu Weber <takeya@bluewin.ch>
|
||||
Tobias Jungel <tobias.jungel@bisdn.de> Tobias Jungel <Tobias.Jungel@gmail.com>
|
||||
Tobias Klauser <tklauser@access.unizh.ch>
|
||||
Tobias Klauser <tklauser@access.unizh.ch> <klauser@access.unizh.ch>
|
||||
Tobias Klauser <tklauser@access.unizh.ch> <tklauser@access.unizh.chbk>
|
||||
Tobias Klauser <tklauser@access.unizh.ch> <tklauser@distanz.ch>
|
||||
Tobias Klauser <tklauser@distanz.ch> <tklauser@nuerscht.ch>
|
||||
Tom Rini <trini@kernel.crashing.org>
|
||||
Tom Yan <tom.ty89@gmail.com>
|
||||
Tomasz Bachorski <tomasz.bachorski@x7f.io> <34866781+nulsoh@users.noreply.github.com>
|
||||
Tomasz Pala <gotar@polanet.pl>
|
||||
Torsten Hilbrich <torsten.hilbrich@gmx.net>
|
||||
Umut Tezduyar Lindskog <umut@tezduyar.com>
|
||||
Vasilis Liaskovitis <vliaskov@gmail.com>
|
||||
Vladislav Vishnyakov <split7fire@yandex.ru>
|
||||
William Jon McCann <jmccann@redhat.com> <william.jon.mccann@gmail.com>
|
||||
Wim van Mourik <wvanmourik@computest.nl> <githubw@use.startmail.com>
|
||||
Yann E. Morin <yann.morin.1998@free.fr>
|
||||
Yin Kangkai <kangkai.yin@intel.com> <kangkai.yin@linux.intel.com>
|
||||
Zachary Winnerman <33329648+winnerman-pythian@users.noreply.github.com>
|
||||
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
|
||||
Łukasz Stelmach <l.stelmach@samsung.com> <stlman@poczta.fm>
|
||||
|
||||
@ -1,6 +1,4 @@
|
||||
# SPDX-License-Identifier: LGPL-2.1+
|
||||
#
|
||||
# Copyright © 2016 Daniel Rusek
|
||||
|
||||
# This is a settings file for OS image generation using mkosi (https://github.com/systemd/mkosi).
|
||||
# Simply invoke "mkosi" in the project directory to build an OS image.
|
||||
@ -63,6 +61,6 @@ BuildPackages=
|
||||
xz-utils
|
||||
|
||||
Packages=
|
||||
libqrencode3
|
||||
libqrencode4
|
||||
locales
|
||||
libidn2-0
|
||||
|
||||
@ -5,11 +5,12 @@
|
||||
|
||||
[Distribution]
|
||||
Distribution=fedora
|
||||
Release=27
|
||||
Release=29
|
||||
|
||||
[Output]
|
||||
Format=raw_btrfs
|
||||
Bootable=yes
|
||||
KernelCommandLine=printk.devkmsg=on
|
||||
|
||||
[Partitions]
|
||||
RootSize=3G
|
||||
|
||||
@ -1,8 +1,4 @@
|
||||
# SPDX-License-Identifier: LGPL-2.1+
|
||||
#
|
||||
# This file is part of systemd.
|
||||
#
|
||||
# Copyright 2016 Daniel Rusek
|
||||
|
||||
# This is a settings file for OS image generation using mkosi (https://github.com/systemd/mkosi).
|
||||
# Simply invoke "mkosi" in the project directory to build an OS image.
|
||||
|
||||
198
.travis.yml
198
.travis.yml
@ -1,77 +1,151 @@
|
||||
sudo: required
|
||||
|
||||
services:
|
||||
- docker
|
||||
|
||||
language: c
|
||||
env:
|
||||
global:
|
||||
- AUTHOR_EMAIL="$(git log -1 $TRAVIS_COMMIT --pretty=\"%aE\")"
|
||||
- CI_MANAGERS="$TRAVIS_BUILD_DIR/travis-ci/managers"
|
||||
- CI_TOOLS="$TRAVIS_BUILD_DIR/travis-ci/tools"
|
||||
- REPO_ROOT="$TRAVIS_BUILD_DIR"
|
||||
|
||||
stages:
|
||||
# Run Coverity periodically instead of for each commit/PR
|
||||
- name: Coverity
|
||||
if: type = cron
|
||||
|
||||
jobs:
|
||||
include:
|
||||
- stage: coverity scan
|
||||
before_script:
|
||||
- sudo apt-get update
|
||||
- stage: Build & test
|
||||
name: Fedora Latest
|
||||
language: bash
|
||||
env:
|
||||
- FEDORA_RELEASE="latest"
|
||||
- CONT_NAME="systemd-fedora-$FEDORA_RELEASE"
|
||||
- DOCKER_EXEC="docker exec -ti $CONT_NAME"
|
||||
before_install:
|
||||
- sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
|
||||
- docker --version
|
||||
- env > .env
|
||||
install:
|
||||
- $CI_MANAGERS/fedora.sh SETUP
|
||||
script:
|
||||
- set -e
|
||||
# Build systemd
|
||||
- $CI_MANAGERS/fedora.sh RUN
|
||||
- set +e
|
||||
after_script:
|
||||
- $CI_MANAGERS/fedora.sh CLEANUP
|
||||
|
||||
- name: Fedora Latest (ASan+UBSan)
|
||||
language: bash
|
||||
env:
|
||||
- FEDORA_RELEASE="latest"
|
||||
- CONT_NAME="systemd-fedora-$FEDORA_RELEASE"
|
||||
- DOCKER_EXEC="docker exec -ti $CONT_NAME"
|
||||
before_install:
|
||||
- sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
|
||||
- docker --version
|
||||
install:
|
||||
- $CI_MANAGERS/fedora.sh SETUP
|
||||
script:
|
||||
- set -e
|
||||
- $CI_MANAGERS/fedora.sh RUN_ASAN
|
||||
- set +e
|
||||
after_script:
|
||||
- $CI_MANAGERS/fedora.sh CLEANUP
|
||||
|
||||
- name: Fedora Latest (clang)
|
||||
language: bash
|
||||
env:
|
||||
- FEDORA_RELEASE="latest"
|
||||
- CONT_NAME="systemd-fedora-$FEDORA_RELEASE"
|
||||
- DOCKER_EXEC="docker exec -ti $CONT_NAME"
|
||||
before_install:
|
||||
- sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
|
||||
- docker --version
|
||||
install:
|
||||
- $CI_MANAGERS/fedora.sh SETUP
|
||||
script:
|
||||
- set -e
|
||||
- $CI_MANAGERS/fedora.sh RUN_CLANG
|
||||
- set +e
|
||||
after_script:
|
||||
- $CI_MANAGERS/fedora.sh CLEANUP
|
||||
|
||||
- name: Fedora Latest (clang ASan+UBSan)
|
||||
language: bash
|
||||
env:
|
||||
- FEDORA_RELEASE="latest"
|
||||
- CONT_NAME="systemd-fedora-$FEDORA_RELEASE"
|
||||
- DOCKER_EXEC="docker exec -ti $CONT_NAME"
|
||||
before_install:
|
||||
- sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
|
||||
- docker --version
|
||||
install:
|
||||
- $CI_MANAGERS/fedora.sh SETUP
|
||||
script:
|
||||
- set -e
|
||||
- $CI_MANAGERS/fedora.sh RUN_CLANG_ASAN
|
||||
- set +e
|
||||
after_script:
|
||||
- $CI_MANAGERS/fedora.sh CLEANUP
|
||||
|
||||
- name: Debian Testing
|
||||
language: bash
|
||||
env:
|
||||
- DEBIAN_RELEASE="testing"
|
||||
- CONT_NAME="systemd-debian-$DEBIAN_RELEASE"
|
||||
- DOCKER_EXEC="docker exec -ti $CONT_NAME"
|
||||
before_install:
|
||||
- sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
|
||||
- docker --version
|
||||
install:
|
||||
- $CI_MANAGERS/debian.sh SETUP
|
||||
script:
|
||||
- set -e
|
||||
- $CI_MANAGERS/debian.sh RUN
|
||||
- set +e
|
||||
after_script:
|
||||
- $CI_MANAGERS/debian.sh CLEANUP
|
||||
|
||||
- stage: Coverity
|
||||
language: bash
|
||||
env:
|
||||
- FEDORA_RELEASE="latest"
|
||||
- CONT_NAME="coverity-fedora-$FEDORA_RELEASE"
|
||||
- DOCKER_EXEC="docker exec -ti $CONT_NAME"
|
||||
- TOOL_BASE="/var/tmp/coverity-scan-analysis"
|
||||
- DOCKER_RUN="docker run -v $TOOL_BASE:$TOOL_BASE:rw --env-file .cov-env"
|
||||
# Coverity env variables
|
||||
- PLATFORM="$(uname)"
|
||||
- TOOL_ARCHIVE="/var/tmp/cov-analysis-$PLATFORM.tgz
|
||||
- SCAN_URL="https://scan.coverity.com"
|
||||
- UPLOAD_URL="https://scan.coverity.com/builds"
|
||||
- COVERITY_SCAN_PROJECT_NAME="$TRAVIS_REPO_SLUG"
|
||||
- COVERITY_SCAN_NOTIFICATION_EMAIL="${AUTHOR_EMAIL}"
|
||||
- COVERITY_SCAN_BRANCH_PATTERN="$TRAVIS_BRANCH"
|
||||
# Encrypted token for systemd/systemd Coverity Scan Analysis,
|
||||
# generated by "travis encrypt -r systemd/systemd COVERITY_SCAN_TOKEN=<TOKEN>"
|
||||
- secure: "lM0IVP2zOG5Ywk3YCbDCQL4WioyzzwtdtpZ+hKDy4BWCZDBJ/FVwIeBsXdMDvlTa3xi+GQ1b7kS2OmTfmG4aSlhU7isuH8SMq1Y4GR5AxfhkR+irUA1A1fntlvhbjIumDGW5wjs0Dt8KogMWS+ZD4eGE59lrVO/TrhMzIe1eHENVLFQJdNq+ZJXU8wxMfHf8lXk0xA8SJTid0XvZBNc4JN6pjJRA8LaOrMNhQYfygFmVQ598kwlu7gf5vbCKFPnIgJAxdIhz12XS9utGohV28IYj9d1DdUGUT+ar3OfADj3X8KFBP4Ymc02pcln3wVgdPtrDbFZh1R9jbmfdXGAH/6tTOJVn8aFySS2Vq9QiBiprWdPsAOLcWMNhnp0lMkASxs9/W26nU7Czo8VbAVWXM1w35plDpnDGR6lk/06dmOZpqu5p3AYr5xIKACIAdPDn0rNpnSWqC750WZ8ZWbHnKuZC5TWML7scVaPiEi7D7rbwqML2rdwx4ZoTZmCHiGByXCIWTfhf0JNQAix5WW3znl+BmDesumPgPj2mX+y6J1WYJrIz12m7qh7KhV/a1ODKM+I91A9rkOA/bPnmhmSSUR7CwgvZt1fC/VwBnaFFtAz9/70kN9Q8tDBXtXidExZwh1e3t5vDG72k3lXwNqpKRvdW3LOxK6lFvqEdMWVUJls="
|
||||
script:
|
||||
# Copy content of CI_DIR into WORKDIR
|
||||
- find $CI_DIR -maxdepth 1 -type f -exec cp -t . {} +
|
||||
# Build container for current user
|
||||
- $CI_SCRIPT_DIR/build-docker-image.sh
|
||||
|
||||
# For kernel version 4.8+
|
||||
- sudo sysctl vsyscall=emulate || true
|
||||
# Prepare environment for Coverity tool
|
||||
- |
|
||||
PLATFORM=`uname`
|
||||
export TOOL_BASE="/tmp/coverity-scan-analysis"
|
||||
export SCAN_URL="https://scan.coverity.com"
|
||||
export UPLOAD_URL="https://scan.coverity.com/builds"
|
||||
export TOOL_ARCHIVE="/tmp/cov-analysis-${PLATFORM}.tgz"
|
||||
|
||||
# Get Coverity tool
|
||||
- $CI_TOOL_DIR/get-coverity.sh
|
||||
- TOOL_DIR="$(find $TOOL_BASE -type d -name 'cov-analysis*')"
|
||||
|
||||
# Export env variables for Coverity scan
|
||||
# Encrypted COVERITY_SCAN_TOKEN env variable
|
||||
# Generated using `travis encrypt -r systemd/systemd COVERITY_SCAN_TOKEN=xxxx`
|
||||
- secure: "jKSz+Y1Mv8xMpQHh7g5lzW7E6HQGndFz/vKDJQ1CVShwFoyjV3Zu+MFS3UYKlh1236zL0Z4dvsYFx/b3Hq8nxZWCrWeZs2NdXgy/wh8LZhxwzcGYigp3sIA/cYdP5rDjFJO0MasNkl25/rml8+eZWz+8/xQic98UQHjSco/EOWtssoRcg0J0c4eDM7bGLfIQWE73NNY1Q1UtWjKmx1kekVrM8dPmHXJ9aERka7bmcbJAcKd6vabs6DQ5AfWccUPIn/EsRYqIJTRxJrFYU6XizANZ1a7Vwk/DWHZUEn2msxcZw5BbAMDTMx0TbfrNkKSHMHuvQUCu6KCBAq414i+LgkMfmQ2SWwKiIUsud1kxXX3ZPl9bxDv1HkvVdcniC/EM7lNEEVwm4meOnjuhI2lhOyOjmP3FTSlMHGP7xlK8DS2k9fqL58vn0BaSjwWgd+2+HuL2+nJmxcK1eLGzKqaostFxrk2Xs2vPZkUdV2nWY/asUrcWHml6YlWDn2eP83pfwxHYsMiEHY/rTKvxeVY+iirO/AphoO+eaYu7LvjKZU1Yx5Z4u/SnGWAiCH0yhMis0bWmgi7SCbw+sDd2uya+aoiLIGiB2ChW7hXHXCue/dif6/gLU7b+L8R00pQwnWdvKUPoIJCmZJYCluTeib4jpW+EmARB2+nR8wms2K9FGKM="
|
||||
before_install:
|
||||
- sudo apt-get -y -o Dpkg::Options::="--force-confnew" install docker-ce
|
||||
- docker --version
|
||||
install:
|
||||
# Install Coverity on the host
|
||||
- $CI_TOOLS/get-coverity.sh
|
||||
# Export necessary env variables for Coverity
|
||||
- env | grep -E "TRAVIS|COV|TOOL|URL" > .cov-env
|
||||
- |
|
||||
docker run -dit --env-file .cov-env \
|
||||
-v ${TOOL_BASE}:${TOOL_BASE}:ro \
|
||||
--name travis_coverity_scan coverity-${TRAVIS_COMMIT}:latest bash
|
||||
# Make sure Coverity script is executable
|
||||
- docker cp tools/coverity.sh travis_coverity_scan:/usr/local/bin
|
||||
# Preconfigure with meson to prevent Coverity from capturing meson metadata
|
||||
# Set compiler flag to prevent emit failure
|
||||
- docker exec -it travis_coverity_scan sh -c "CFLAGS='-D_Float128=long\ double -D_Float64=double -D_Float64x=long\ double -D_Float32=float -D_Float32x=double' meson cov-build -Dman=false"
|
||||
# Run Coverity Analysis
|
||||
- docker exec -it travis_coverity_scan coverity.sh build
|
||||
- docker exec -it travis_coverity_scan coverity.sh upload
|
||||
# Pull a Docker image and start a new container
|
||||
- $CI_MANAGERS/fedora.sh SETUP
|
||||
script:
|
||||
- set -e
|
||||
# Preconfigure with meson to prevent Coverity from capturing meson metadata
|
||||
# Set compiler flag to prevent emit failure
|
||||
- $DOCKER_EXEC sh -c "CFLAGS='-D_Float128=long\ double -D_Float64=double -D_Float64x=long\ double -D_Float32=float -D_Float32x=double' meson cov-build -Dman=false"
|
||||
# Run Coverity
|
||||
- $DOCKER_EXEC tools/coverity.sh build
|
||||
- $DOCKER_EXEC tools/coverity.sh upload
|
||||
|
||||
# Specify the order of stages and conditions
|
||||
stages:
|
||||
- name: coverity scan
|
||||
if: type = cron
|
||||
|
||||
env:
|
||||
global:
|
||||
- ADMIN_EMAIL=macermak@redhat.com
|
||||
|
||||
- AUTHOR_NAME="$(git log -1 $TRAVIS_COMMIT --pretty=\"%aN\")"
|
||||
- AUTHOR_EMAIL="$(git log -1 $TRAVIS_COMMIT --pretty=\"%aE\")"
|
||||
|
||||
- CI_DIR="$TRAVIS_BUILD_DIR/travis-ci"
|
||||
- CI_TOOL_DIR="$CI_DIR/tools"
|
||||
- CI_SCRIPT_DIR="$CI_DIR/scripts"
|
||||
|
||||
notifications:
|
||||
email:
|
||||
recipients:
|
||||
- ${ADMIN_EMAIL}
|
||||
- set +e
|
||||
after_script:
|
||||
- $CI_MANAGERS/fedora.sh CLEANUP
|
||||
|
||||
6
.vimrc
6
.vimrc
@ -4,7 +4,7 @@
|
||||
" You should consider setting 'set secure' as well, which is highly
|
||||
" recommended!
|
||||
|
||||
" Note that we set a line width of 119 for .c and XML files, but for everything
|
||||
" Note that we set a line width of 109 for .c and XML files, but for everything
|
||||
" else (such as journal catalog files, unit files, README files) we stick to a
|
||||
" more conservative 79 characters.
|
||||
|
||||
@ -16,5 +16,5 @@ set shiftwidth=8
|
||||
set expandtab
|
||||
set makeprg=GCC_COLORS=\ make
|
||||
set tw=79
|
||||
au BufRead,BufNewFile *.xml set tw=119 shiftwidth=2 smarttab
|
||||
au FileType c set tw=119
|
||||
au BufRead,BufNewFile *.xml set tw=109 shiftwidth=2 smarttab
|
||||
au FileType c set tw=109
|
||||
|
||||
621
NEWS
621
NEWS
@ -1,5 +1,506 @@
|
||||
systemd System and Service Manager
|
||||
|
||||
CHANGES WITH 240:
|
||||
|
||||
* NoNewPrivileges=yes has been set for all long-running services
|
||||
implemented by systemd. Previously, this was problematic due to
|
||||
SELinux (as this would also prohibit the transition from PID1's label
|
||||
to the service's label). This restriction has since been lifted, but
|
||||
an SELinux policy update is required.
|
||||
(See e.g. https://github.com/fedora-selinux/selinux-policy/pull/234.)
|
||||
|
||||
* DynamicUser=yes is dropped from systemd-networkd.service,
|
||||
systemd-resolved.service and systemd-timesyncd.service, which was
|
||||
enabled in v239 for systemd-networkd.service and systemd-resolved.service,
|
||||
and since v236 for systemd-timesyncd.service. The users and groups
|
||||
systemd-network, systemd-resolve and systemd-timesync are created
|
||||
by systemd-sysusers again. Distributors or system administrators
|
||||
may need to create these users and groups if they not exist (or need
|
||||
to re-enable DynamicUser= for those units) while upgrading systemd.
|
||||
|
||||
* When unit files are loaded from disk, previously systemd would
|
||||
sometimes (depending on the unit loading order) load units from the
|
||||
target path of symlinks in .wants/ or .requires/ directories of other
|
||||
units. This meant that unit could be loaded from different paths
|
||||
depending on whether the unit was requested explicitly or as a
|
||||
dependency of another unit, not honouring the priority of directories
|
||||
in search path. It also meant that it was possible to successfully
|
||||
load and start units which are not found in the unit search path, as
|
||||
long as they were requested as a dependency and linked to from
|
||||
.wants/ or .requires/. The target paths of those symlinks are not
|
||||
used for loading units anymore and the unit file must be found in
|
||||
the search path.
|
||||
|
||||
* A new service type has been added: Type=exec. It's very similar to
|
||||
Type=simple but ensures the service manager will wait for both fork()
|
||||
and execve() of the main service binary to complete before proceeding
|
||||
with follow-up units. This is primarily useful so that the manager
|
||||
propagates any errors in the preparation phase of service execution
|
||||
back to the job that requested the unit to be started. For example,
|
||||
consider a service that has ExecStart= set to a file system binary
|
||||
that doesn't exist. With Type=simple starting the unit would be
|
||||
considered instantly successful, as only fork() has to complete
|
||||
successfully and the manager does not wait for execve(), and hence
|
||||
its failure is seen "too late". With the new Type=exec service type
|
||||
starting the unit will fail, as the manager will wait for the
|
||||
execve() and notice its failure, which is then propagated back to the
|
||||
start job.
|
||||
|
||||
NOTE: with the next release 241 of systemd we intend to change the
|
||||
systemd-run tool to default to Type=exec for transient services
|
||||
started by it. This should be mostly safe, but in specific corner
|
||||
cases might result in problems, as the systemd-run tool will then
|
||||
block on NSS calls (such as user name look-ups due to User=) done
|
||||
between the fork() and execve(), which under specific circumstances
|
||||
might cause problems. It is recommended to specify "-p Type=simple"
|
||||
explicitly in the few cases where this applies. For regular,
|
||||
non-transient services (i.e. those defined with unit files on disk)
|
||||
we will continue to default to Type=simple.
|
||||
|
||||
* The Linux kernel's current default RLIMIT_NOFILE resource limit for
|
||||
userspace processes is set to 1024 (soft) and 4096
|
||||
(hard). Previously, systemd passed this on unmodified to all
|
||||
processes it forked off. With this systemd release the hard limit
|
||||
systemd passes on is increased to 512K, overriding the kernel's
|
||||
defaults and substantially increasing the number of simultaneous file
|
||||
descriptors unprivileged userspace processes can allocate. Note that
|
||||
the soft limit remains at 1024 for compatibility reasons: the
|
||||
traditional UNIX select() call cannot deal with file descriptors >=
|
||||
1024 and increasing the soft limit globally might thus result in
|
||||
programs unexpectedly allocating a high file descriptor and thus
|
||||
failing abnormally when attempting to use it with select() (of
|
||||
course, programs shouldn't use select() anymore, and prefer
|
||||
poll()/epoll, but the call unfortunately remains undeservedly popular
|
||||
at this time). This change reflects the fact that file descriptor
|
||||
handling in the Linux kernel has been optimized in more recent
|
||||
kernels and allocating large numbers of them should be much cheaper
|
||||
both in memory and in performance than it used to be. Programs that
|
||||
want to take benefit of the increased limit have to "opt-in" into
|
||||
high file descriptors explicitly by raising their soft limit. Of
|
||||
course, when they do that they must acknowledge that they cannot use
|
||||
select() anymore (and neither can any shared library they use — or
|
||||
any shared library used by any shared library they use and so on).
|
||||
Which default hard limit is most appropriate is of course hard to
|
||||
decide. However, given reports that ~300K file descriptors are used
|
||||
in real-life applications we believe 512K is sufficiently high as new
|
||||
default for now. Note that there are also reports that using very
|
||||
high hard limits (e.g. 1G) is problematic: some software allocates
|
||||
large arrays with one element for each potential file descriptor
|
||||
(Java, …) — a high hard limit thus triggers excessively large memory
|
||||
allocations in these applications. Hopefully, the new default of 512K
|
||||
is a good middle ground: higher than what real-life applications
|
||||
currently need, and low enough for avoid triggering excessively large
|
||||
allocations in problematic software. (And yes, somebody should fix
|
||||
Java.)
|
||||
|
||||
* The fs.nr_open and fs.file-max sysctls are now automatically bumped
|
||||
to the highest possible values, as separate accounting of file
|
||||
descriptors is no longer necessary, as memcg tracks them correctly as
|
||||
part of the memory accounting anyway. Thus, from the four limits on
|
||||
file descriptors currently enforced (fs.file-max, fs.nr_open,
|
||||
RLIMIT_NOFILE hard, RLIMIT_NOFILE soft) we turn off the first two,
|
||||
and keep only the latter two. A set of build-time options
|
||||
(-Dbump-proc-sys-fs-file-max=no and -Dbump-proc-sys-fs-nr-open=no)
|
||||
has been added to revert this change in behaviour, which might be
|
||||
an option for systems that turn off memcg in the kernel.
|
||||
|
||||
* When no /etc/locale.conf file exists (and hence no locale settings
|
||||
are in place), systemd will now use the "C.UTF-8" locale by default,
|
||||
and set LANG= to it. This locale is supported by various
|
||||
distributions including Fedora, with clear indications that upstream
|
||||
glibc is going to make it available too. This locale enables UTF-8
|
||||
mode by default, which appears appropriate for 2018.
|
||||
|
||||
* The "net.ipv4.conf.all.rp_filter" sysctl will now be set to 2 by
|
||||
default. This effectively switches the RFC3704 Reverse Path filtering
|
||||
from Strict mode to Loose mode. This is more appropriate for hosts
|
||||
that have multiple links with routes to the same networks (e.g.
|
||||
a client with a Wi-Fi and Ethernet both connected to the internet).
|
||||
|
||||
Consult the kernel documentation for details on this sysctl:
|
||||
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
|
||||
|
||||
* CPUAccounting=yes no longer enables the CPU controller when using
|
||||
kernel 4.15+ and the unified cgroup hierarchy, as required accounting
|
||||
statistics are now provided independently from the CPU controller.
|
||||
|
||||
* Support for disabling a particular cgroup controller within a sub-tree
|
||||
has been added through the DisableControllers= directive.
|
||||
|
||||
* cgroup_no_v1=all on the kernel command line now also implies
|
||||
using the unified cgroup hierarchy, unless one explicitly passes
|
||||
systemd.unified_cgroup_hierarchy=0 on the kernel command line.
|
||||
|
||||
* The new "MemoryMin=" unit file property may now be used to set the
|
||||
memory usage protection limit of processes invoked by the unit. This
|
||||
controls the cgroupsv2 memory.min attribute. Similarly, the new
|
||||
"IODeviceLatencyTargetSec=" property has been added, wrapping the new
|
||||
cgroupsv2 io.latency cgroup property for configuring per-service I/O
|
||||
latency.
|
||||
|
||||
* systemd now supports the cgroupsv2 devices BPF logic, as counterpart
|
||||
to the cgroupsv1 "devices" cgroup controller.
|
||||
|
||||
* systemd-escape now is able to combine --unescape with --template. It
|
||||
also learnt a new option --instance for extracting and unescaping the
|
||||
instance part of a unit name.
|
||||
|
||||
* sd-bus now provides the sd_bus_message_readv() which is similar to
|
||||
sd_bus_message_read() but takes a va_list object. The pair
|
||||
sd_bus_set_method_call_timeout() and sd_bus_get_method_call_timeout()
|
||||
has been added for configuring the default method call timeout to
|
||||
use. sd_bus_error_move() may be used to efficiently move the contents
|
||||
from one sd_bus_error structure to another, invalidating the
|
||||
source. sd_bus_set_close_on_exit() and sd_bus_get_close_on_exit() may
|
||||
be used to control whether a bus connection object is automatically
|
||||
flushed when an sd-event loop is exited.
|
||||
|
||||
* When processing classic BSD syslog log messages, journald will now
|
||||
save the original time-stamp string supplied in the new
|
||||
SYSLOG_TIMESTAMP= journal field. This permits consumers to
|
||||
reconstruct the original BSD syslog message more correctly.
|
||||
|
||||
* StandardOutput=/StandardError= in service files gained support for
|
||||
new "append:…" parameters, for connecting STDOUT/STDERR of a service
|
||||
to a file, and appending to it.
|
||||
|
||||
* The signal to use as last step of killing of unit processes is now
|
||||
configurable. Previously it was hard-coded to SIGKILL, which may now
|
||||
be overridden with the new KillSignal= setting. Note that this is the
|
||||
signal used when regular termination (i.e. SIGTERM) does not suffice.
|
||||
Similarly, the signal used when aborting a program in case of a
|
||||
watchdog timeout may now be configured too (WatchdogSignal=).
|
||||
|
||||
* The XDG_SESSION_DESKTOP environment variable may now be configured in
|
||||
the pam_systemd argument line, using the new desktop= switch. This is
|
||||
useful to initialize it properly from a display manager without
|
||||
having to touch C code.
|
||||
|
||||
* Most configuration options that previously accepted percentage values
|
||||
now also accept permille values with the '‰' suffix (instead of '%').
|
||||
|
||||
* systemd-resolved may now optionally use OpenSSL instead of GnuTLS for
|
||||
DNS-over-TLS.
|
||||
|
||||
* systemd-resolved's configuration file resolved.conf gained a new
|
||||
option ReadEtcHosts= which may be used to turn off processing and
|
||||
honoring /etc/hosts entries.
|
||||
|
||||
* The "--wait" switch may now be passed to "systemctl
|
||||
is-system-running", in which case the tool will synchronously wait
|
||||
until the system finished start-up.
|
||||
|
||||
* hostnamed gained a new bus call to determine the DMI product UUID.
|
||||
|
||||
* On x86-64 systemd will now prefer using the RDRAND processor
|
||||
instruction over /dev/urandom whenever it requires randomness that
|
||||
neither has to be crypto-grade nor should be reproducible. This
|
||||
should substantially reduce the amount of entropy systemd requests
|
||||
from the kernel during initialization on such systems, though not
|
||||
reduce it to zero. (Why not zero? systemd still needs to allocate
|
||||
UUIDs and such uniquely, which require high-quality randomness.)
|
||||
|
||||
* networkd gained support for Foo-Over-UDP, ERSPAN and ISATAP
|
||||
tunnels. It also gained a new option ForceDHCPv6PDOtherInformation=
|
||||
for forcing the "Other Information" bit in IPv6 RA messages. The
|
||||
bonding logic gained four new options AdActorSystemPriority=,
|
||||
AdUserPortKey=, AdActorSystem= for configuring various 802.3ad
|
||||
aspects, and DynamicTransmitLoadBalancing= for enabling dynamic
|
||||
shuffling of flows. The tunnel logic gained a new
|
||||
IPv6RapidDeploymentPrefix= option for configuring IPv6 Rapid
|
||||
Deployment. The policy rule logic gained four new options IPProtocol=,
|
||||
SourcePort= and DestinationPort=, InvertRule=. The bridge logic gained
|
||||
support for the MulticastToUnicast= option. networkd also gained
|
||||
support for configuring static IPv4 ARP or IPv6 neighbor entries.
|
||||
|
||||
* .preset files (as read by 'systemctl preset') may now be used to
|
||||
instantiate services.
|
||||
|
||||
* /etc/crypttab now understands the sector-size= option to configure
|
||||
the sector size for an encrypted partition.
|
||||
|
||||
* Key material for encrypted disks may now be placed on a formatted
|
||||
medium, and referenced from /etc/crypttab by the UUID of the file
|
||||
system, followed by "=" suffixed by the path to the key file.
|
||||
|
||||
* The "collect" udev component has been removed without replacement, as
|
||||
it is neither used nor maintained.
|
||||
|
||||
* When the RuntimeDirectory=, StateDirectory=, CacheDirectory=,
|
||||
LogsDirectory=, ConfigurationDirectory= settings are used in a
|
||||
service the executed processes will now receive a set of environment
|
||||
variables containing the full paths of these directories.
|
||||
Specifically, RUNTIME_DIRECTORY=, STATE_DIRECTORY, CACHE_DIRECTORY,
|
||||
LOGS_DIRECTORY, CONFIGURATION_DIRECTORY are now set if these options
|
||||
are used. Note that these options may be used multiple times per
|
||||
service in which case the resulting paths will be concatenated and
|
||||
separated by colons.
|
||||
|
||||
* Predictable interface naming has been extended to cover InfiniBand
|
||||
NICs. They will be exposed with an "ib" prefix.
|
||||
|
||||
* tmpfiles.d/ line types may now be suffixed with a '-' character, in
|
||||
which case the respective line failing is ignored.
|
||||
|
||||
* .link files may now be used to configure the equivalent to the
|
||||
"ethtool advertise" commands.
|
||||
|
||||
* The sd-device.h and sd-hwdb.h APIs are now exported, as an
|
||||
alternative to libudev.h. Previously, the latter was just an internal
|
||||
wrapper around the former, but now these two APIs are exposed
|
||||
directly.
|
||||
|
||||
* sd-id128.h gained a new function sd_id128_get_boot_app_specific()
|
||||
which calculates an app-specific boot ID similar to how
|
||||
sd_id128_get_machine_app_specific() generates an app-specific machine
|
||||
ID.
|
||||
|
||||
* A new tool systemd-id128 has been added that can be used to determine
|
||||
and generate various 128bit IDs.
|
||||
|
||||
* /etc/os-release gained two new standardized fields DOCUMENTATION_URL=
|
||||
and LOGO=.
|
||||
|
||||
* systemd-hibernate-resume-generator will now honor the "noresume"
|
||||
kernel command line option, in which case it will bypass resuming
|
||||
from any hibernated image.
|
||||
|
||||
* The systemd-sleep.conf configuration file gained new options
|
||||
AllowSuspend=, AllowHibernation=, AllowSuspendThenHibernate=,
|
||||
AllowHybridSleep= for prohibiting specific sleep modes even if the
|
||||
kernel exports them.
|
||||
|
||||
* portablectl is now officially supported and has thus moved to
|
||||
/usr/bin/.
|
||||
|
||||
* bootctl learnt the two new commands "set-default" and "set-oneshot"
|
||||
for setting the default boot loader item to boot to (either
|
||||
persistently or only for the next boot). This is currently only
|
||||
compatible with sd-boot, but may be implemented on other boot loaders
|
||||
too, that follow the boot loader interface. The updated interface is
|
||||
now documented here:
|
||||
|
||||
https://systemd.io/BOOT_LOADER_INTERFACE
|
||||
|
||||
* A new kernel command line option systemd.early_core_pattern= is now
|
||||
understood which may be used to influence the core_pattern PID 1
|
||||
installs during early boot.
|
||||
|
||||
* busctl learnt two new options -j and --json= for outputting method
|
||||
call replies, properties and monitoring output in JSON.
|
||||
|
||||
* journalctl's JSON output now supports simple ANSI coloring as well as
|
||||
a new "json-seq" mode for generating RFC7464 output.
|
||||
|
||||
* Unit files now support the %g/%G specifiers that resolve to the UNIX
|
||||
group/GID of the service manager runs as, similar to the existing
|
||||
%u/%U specifiers that resolve to the UNIX user/UID.
|
||||
|
||||
* systemd-logind learnt a new global configuration option
|
||||
UserStopDelaySec= that may be set in logind.conf. It specifies how
|
||||
long the systemd --user instance shall remain started after a user
|
||||
logs out. This is useful to speed up repetitive re-connections of the
|
||||
same user, as it means the user's service manager doesn't have to be
|
||||
stopped/restarted on each iteration, but can be reused between
|
||||
subsequent options. This setting defaults to 10s. systemd-logind also
|
||||
exports two new properties on its Manager D-Bus objects indicating
|
||||
whether the system's lid is currently closed, and whether the system
|
||||
is on AC power.
|
||||
|
||||
* systemd gained support for a generic boot counting logic, which
|
||||
generically permits automatic reverting to older boot loader entries
|
||||
if newer updated ones don't work. The boot loader side is implemented
|
||||
in sd-boot, but is kept open for other boot loaders too. For details
|
||||
see:
|
||||
|
||||
https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT
|
||||
|
||||
* The SuccessAction=/FailureAction= unit file settings now learnt two
|
||||
new parameters: "exit" and "exit-force", which result in immediate
|
||||
exiting of the service manager, and are only useful in systemd --user
|
||||
and container environments.
|
||||
|
||||
* Unit files gained support for a pair of options
|
||||
FailureActionExitStatus=/SuccessActionExitStatus= for configuring the
|
||||
exit status to use as service manager exit status when
|
||||
SuccessAction=/FailureAction= is set to exit or exit-force.
|
||||
|
||||
* A pair of LogRateLimitIntervalSec=/LogRateLimitBurst= per-service
|
||||
options may now be used to configure the log rate limiting applied by
|
||||
journald per-service.
|
||||
|
||||
* systemd-analyze gained a new verb "timespan" for parsing and
|
||||
normalizing time span values (i.e. strings like "5min 7s 8us").
|
||||
|
||||
* systemd-analyze also gained a new verb "security" for analyzing the
|
||||
security and sand-boxing settings of services in order to determine an
|
||||
"exposure level" for them, indicating whether a service would benefit
|
||||
from more sand-boxing options turned on for them.
|
||||
|
||||
* "systemd-analyze syscall-filter" will now also show system calls
|
||||
supported by the local kernel but not included in any of the defined
|
||||
groups.
|
||||
|
||||
* .nspawn files now understand the Ephemeral= setting, matching the
|
||||
--ephemeral command line switch.
|
||||
|
||||
* sd-event gained the new APIs sd_event_source_get_floating() and
|
||||
sd_event_source_set_floating() for controlling whether a specific
|
||||
event source is "floating", i.e. destroyed along with the even loop
|
||||
object itself.
|
||||
|
||||
* Unit objects on D-Bus gained a new "Refs" property that lists all
|
||||
clients that currently have a reference on the unit (to ensure it is
|
||||
not unloaded).
|
||||
|
||||
* The JoinControllers= option in system.conf is no longer supported, as
|
||||
it didn't work correctly, is hard to support properly, is legacy (as
|
||||
the concept only exists on cgroupsv1) and apparently wasn't used.
|
||||
|
||||
* Journal messages that are generated whenever a unit enters the failed
|
||||
state are now tagged with a unique MESSAGE_ID. Similarly, messages
|
||||
generated whenever a service process exits are now made recognizable,
|
||||
too. A taged message is also emitted whenever a unit enters the
|
||||
"dead" state on success.
|
||||
|
||||
* systemd-run gained a new switch --working-directory= for configuring
|
||||
the working directory of the service to start. A shortcut -d is
|
||||
equivalent, setting the working directory of the service to the
|
||||
current working directory of the invoking program. The new --shell
|
||||
(or just -S) option has been added for invoking the $SHELL of the
|
||||
caller as a service, and implies --pty --same-dir --wait --collect
|
||||
--service-type=exec. Or in other words, "systemd-run -S" is now the
|
||||
quickest way to quickly get an interactive in a fully clean and
|
||||
well-defined system service context.
|
||||
|
||||
* machinectl gained a new verb "import-fs" for importing an OS tree
|
||||
from a directory. Moreover, when a directory or tarball is imported
|
||||
and single top-level directory found with the OS itself below the OS
|
||||
tree is automatically mangled and moved one level up.
|
||||
|
||||
* systemd-importd will no longer set up an implicit btrfs loop-back
|
||||
file system on /var/lib/machines. If one is already set up, it will
|
||||
continue to be used.
|
||||
|
||||
* A new generator "systemd-run-generator" has been added. It will
|
||||
synthesize a unit from one or more program command lines included in
|
||||
the kernel command line. This is very useful in container managers
|
||||
for example:
|
||||
|
||||
# systemd-nspawn -i someimage.raw -b systemd.run='"some command line"'
|
||||
|
||||
This will run "systemd-nspawn" on an image, invoke the specified
|
||||
command line and immediately shut down the container again, returning
|
||||
the command line's exit code.
|
||||
|
||||
* The block device locking logic is now documented:
|
||||
|
||||
https://systemd.io/BLOCK_DEVICE_LOCKING
|
||||
|
||||
* loginctl and machinectl now optionally output the various tables in
|
||||
JSON using the --output= switch. It is our intention to add similar
|
||||
support to systemctl and all other commands.
|
||||
|
||||
* udevadm's query and trigger verb now optionally take a .device unit
|
||||
name as argument.
|
||||
|
||||
* systemd-udevd's network naming logic now understands a new
|
||||
net.naming-scheme= kernel command line switch, which may be used to
|
||||
pick a specific version of the naming scheme. This helps stabilizing
|
||||
interface names even as systemd/udev are updated and the naming logic
|
||||
is improved.
|
||||
|
||||
* sd-id128.h learnt two new auxiliary helpers: sd_id128_is_allf() and
|
||||
SD_ID128_ALLF to test if a 128bit ID is set to all 0xFF bytes, and to
|
||||
initialize one to all 0xFF.
|
||||
|
||||
* After loading the SELinux policy systemd will now recursively relabel
|
||||
all files and directories listed in
|
||||
/run/systemd/relabel-extra.d/*.relabel (which should be simple
|
||||
newline separated lists of paths) in addition to the ones it already
|
||||
implicitly relabels in /run, /dev and /sys. After the relabelling is
|
||||
completed the *.relabel files (and /run/systemd/relabel-extra.d/) are
|
||||
removed. This is useful to permit initrds (i.e. code running before
|
||||
the SELinux policy is in effect) to generate files in the host
|
||||
filesystem safely and ensure that the correct label is applied during
|
||||
the transition to the host OS.
|
||||
|
||||
* KERNEL API BREAKAGE: Linux kernel 4.18 changed behaviour regarding
|
||||
mknod() handling in user namespaces. Previously mknod() would always
|
||||
fail with EPERM in user namespaces. Since 4.18 mknod() will succeed
|
||||
but device nodes generated that way cannot be opened, and attempts to
|
||||
open them result in EPERM. This breaks the "graceful fallback" logic
|
||||
in systemd's PrivateDevices= sand-boxing option. This option is
|
||||
implemented defensively, so that when systemd detects it runs in a
|
||||
restricted environment (such as a user namespace, or an environment
|
||||
where mknod() is blocked through seccomp or absence of CAP_SYS_MKNOD)
|
||||
where device nodes cannot be created the effect of PrivateDevices= is
|
||||
bypassed (following the logic that 2nd-level sand-boxing is not
|
||||
essential if the system systemd runs in is itself already sand-boxed
|
||||
as a whole). This logic breaks with 4.18 in container managers where
|
||||
user namespacing is used: suddenly PrivateDevices= succeeds setting
|
||||
up a private /dev/ file system containing devices nodes — but when
|
||||
these are opened they don't work.
|
||||
|
||||
At this point is is recommended that container managers utilizing
|
||||
user namespaces that intend to run systemd in the payload explicitly
|
||||
block mknod() with seccomp or similar, so that the graceful fallback
|
||||
logic works again.
|
||||
|
||||
We are very sorry for the breakage and the requirement to change
|
||||
container configurations for newer kernels. It's purely caused by an
|
||||
incompatible kernel change. The relevant kernel developers have been
|
||||
notified about this userspace breakage quickly, but they chose to
|
||||
ignore it.
|
||||
|
||||
Contributions from: afg, Alan Jenkins, Aleksei Timofeyev, Alexander
|
||||
Filippov, Alexander Kurtz, Alexey Bogdanenko, Andreas Henriksson,
|
||||
Andrew Jorgensen, Anita Zhang, apnix-uk, Arkan49, Arseny Maslennikov,
|
||||
asavah, Asbjørn Apeland, aszlig, Bastien Nocera, Ben Boeckel, Benedikt
|
||||
Morbach, Benjamin Berg, Bruce Zhang, Carlo Caione, Cedric Viou, Chen
|
||||
Qi, Chris Chiu, Chris Down, Chris Morin, Christian Rebischke, Claudius
|
||||
Ellsel, Colin Guthrie, dana, Daniel, Daniele Medri, Daniel Kahn
|
||||
Gillmor, Daniel Rusek, Daniel van Vugt, Dariusz Gadomski, Dave Reisner,
|
||||
David Anderson, Davide Cavalca, David Leeds, David Malcolm, David
|
||||
Strauss, David Tardon, Dimitri John Ledkov, Dmitry Torokhov, dj-kaktus,
|
||||
Dongsu Park, Elias Probst, Emil Soleyman, Erik Kooistra, Ervin Peters,
|
||||
Evgeni Golov, Evgeny Vereshchagin, Fabrice Fontaine, Faheel Ahmad,
|
||||
Faizal Luthfi, Felix Yan, Filipe Brandenburger, Franck Bui, Frank
|
||||
Schaefer, Frantisek Sumsal, Gautier Husson, Gianluca Boiano, Giuseppe
|
||||
Scrivano, glitsj16, Hans de Goede, Harald Hoyer, Harry Mallon, Harshit
|
||||
Jain, Helmut Grohne, Henry Tung, Hui Yiqun, imayoda, Insun Pyo, Iwan
|
||||
Timmer, Jan Janssen, Jan Pokorný, Jan Synacek, Jason A. Donenfeld,
|
||||
javitoom, Jérémy Nouhaud, Jeremy Su, Jiuyang Liu, João Paulo Rechi
|
||||
Vita, Joe Hershberger, Joe Rayhawk, Joerg Behrmann, Joerg Steffens,
|
||||
Jonas Dorel, Jon Ringle, Josh Soref, Julian Andres Klode, Jun Bo Bi,
|
||||
Jürg Billeter, Keith Busch, Khem Raj, Kirill Marinushkin, Larry
|
||||
Bernstone, Lennart Poettering, Lion Yang, Li Song, Lorenz
|
||||
Hübschle-Schneider, Lubomir Rintel, Lucas Werkmeister, Ludwin Janvier,
|
||||
Lukáš Nykrýn, Luke Shumaker, mal, Marc-Antoine Perennou, Marcin
|
||||
Skarbek, Marco Trevisan (Treviño), Marian Cepok, Mario Hros, Marko
|
||||
Myllynen, Markus Grimm, Martin Pitt, Martin Sobotka, Martin Wilck,
|
||||
Mathieu Trudel-Lapierre, Matthew Leeds, Michael Biebl, Michael Olbrich,
|
||||
Michael 'pbone' Pobega, Michael Scherer, Michal Koutný, Michal
|
||||
Sekletar, Michal Soltys, Mike Gilbert, Mike Palmer, Muhammet Kara, Neal
|
||||
Gompa, Neil Brown, Network Silence, Niklas Tibbling, Nikolas Nyby,
|
||||
Nogisaka Sadata, Oliver Smith, Patrik Flykt, Pavel Hrdina, Paweł
|
||||
Szewczyk, Peter Hutterer, Piotr Drąg, Ray Strode, Reinhold Mueller,
|
||||
Renaud Métrich, Roman Gushchin, Ronny Chevalier, Rubén Suárez Alvarez,
|
||||
Ruixin Bao, RussianNeuroMancer, Ryutaroh Matsumoto, Saleem Rashid, Sam
|
||||
Morris, Samuel Morris, Sandy Carter, scootergrisen, Sébastien Bacher,
|
||||
Sergey Ptashnick, Shawn Landden, Shengyao Xue, Shih-Yuan Lee
|
||||
(FourDollars), Silvio Knizek, Sjoerd Simons, Stasiek Michalski, Stephen
|
||||
Gallagher, Steven Allen, Steve Ramage, Susant Sahani, Sven Joachim,
|
||||
Sylvain Plantefève, Tanu Kaskinen, Tejun Heo, Thiago Macieira, Thomas
|
||||
Blume, Thomas Haller, Thomas H. P. Andersen, Tim Ruffing, TJ, Tobias
|
||||
Jungel, Todd Walton, Tommi Rantala, Tomsod M, Tony Novak, Tore
|
||||
Anderson, Trevonn, Victor Laskurain, Victor Tapia, Violet Halo, Vojtech
|
||||
Trefny, welaq, William A. Kennington III, William Douglas, Wyatt Ward,
|
||||
Xiang Fan, Xi Ruoyao, Xuanwo, Yann E. Morin, YmrDtnJu, Yu Watanabe,
|
||||
Zbigniew Jędrzejewski-Szmek, Zhang Xianwei, Zsolt Dollenstein
|
||||
|
||||
— Warsaw, 2018-12-21
|
||||
|
||||
CHANGES WITH 239:
|
||||
|
||||
* NETWORK INTERFACE DEVICE NAMING CHANGES: systemd-udevd's "net_id"
|
||||
@ -82,7 +583,28 @@ CHANGES WITH 239:
|
||||
|
||||
* systemd-resolved.service and systemd-networkd.service now set
|
||||
DynamicUser=yes. The users systemd-resolve and systemd-network are
|
||||
not created by systemd-sysusers.
|
||||
not created by systemd-sysusers anymore.
|
||||
|
||||
NOTE: This has a chance of breaking nss-ldap and similar NSS modules
|
||||
that embedd a network facing module into any process using getpwuid()
|
||||
or related call: the dynamic allocation of the user ID for
|
||||
systemd-resolved.service means the service manager has to check NSS
|
||||
if the user name is already taken when forking off the service. Since
|
||||
the user in the common case won't be defined in /etc/passwd the
|
||||
lookup is likely to trigger nss-ldap which in turn might use NSS to
|
||||
ask systemd-resolved for hostname lookups. This will hence result in
|
||||
a deadlock: a user name lookup in order to start
|
||||
systemd-resolved.service will result in a host name lookup for which
|
||||
systemd-resolved.service needs to be started already. There are
|
||||
multiple ways to work around this problem: pre-allocate the
|
||||
"systemd-resolve" user on such systems, so that nss-ldap won't be
|
||||
triggered; or use a different NSS package that doesn't do networking
|
||||
in-process but provides a local asynchronous name cache; or configure
|
||||
the NSS package to avoid lookups for UIDs in the range `pkg-config
|
||||
systemd --variable=dynamicuidmin` … `pkg-config systemd
|
||||
--variable=dynamicuidmax`, so that it does not consider itself
|
||||
authoritative for the same UID range systemd allocates dynamic users
|
||||
from.
|
||||
|
||||
* The systemd-resolve tool has been renamed to resolvectl (it also
|
||||
remains available under the old name, for compatibility), and its
|
||||
@ -95,7 +617,7 @@ CHANGES WITH 239:
|
||||
Debian and FreeBSD resolvconf tool.
|
||||
|
||||
* Support for suspend-then-hibernate has been added, i.e. a sleep mode
|
||||
where the system initially suspends, and after a time-out resumes and
|
||||
where the system initially suspends, and after a timeout resumes and
|
||||
hibernates again.
|
||||
|
||||
* networkd's ClientIdentifier= now accepts a new option "duid-only". If
|
||||
@ -300,13 +822,13 @@ CHANGES WITH 239:
|
||||
* New documentation has been added to document cgroups delegation,
|
||||
portable services and the various code quality tools we have set up:
|
||||
|
||||
https://github.com/systemd/systemd/blob/master/doc/CGROUP_DELEGATION.md
|
||||
https://github.com/systemd/systemd/blob/master/doc/PORTABLE_SERVICES.md
|
||||
https://github.com/systemd/systemd/blob/master/doc/CODE_QUALITY.md
|
||||
https://github.com/systemd/systemd/blob/master/docs/CGROUP_DELEGATION.md
|
||||
https://github.com/systemd/systemd/blob/master/docs/PORTABLE_SERVICES.md
|
||||
https://github.com/systemd/systemd/blob/master/docs/CODE_QUALITY.md
|
||||
|
||||
* The Boot Loader Specification has been added to the source tree.
|
||||
|
||||
https://github.com/systemd/systemd/blob/master/doc/BOOT_LOADER_SPECIFICATION.md
|
||||
https://github.com/systemd/systemd/blob/master/docs/BOOT_LOADER_SPECIFICATION.md
|
||||
|
||||
While moving it into our source tree we have updated it and further
|
||||
changes are now accepted through the usual github PR workflow.
|
||||
@ -546,10 +1068,9 @@ CHANGES WITH 237:
|
||||
different from what the documentation said, and not particularly
|
||||
useful, as repeated systemd-tmpfiles invocations would not be
|
||||
idempotent and grow such files without bounds. With this release
|
||||
behaviour has been altered slightly, to match what the documentation
|
||||
says: lines of this type only have an effect if the indicated files
|
||||
don't exist yet, and only then the argument string is written to the
|
||||
file.
|
||||
behaviour has been altered to match what the documentation says:
|
||||
lines of this type only have an effect if the indicated files don't
|
||||
exist yet, and only then the argument string is written to the file.
|
||||
|
||||
* FUTURE INCOMPATIBILITY: In systemd v238 we intend to slightly change
|
||||
systemd-tmpfiles behaviour: previously, read-only files owned by root
|
||||
@ -1622,7 +2143,7 @@ CHANGES WITH 233:
|
||||
* Documentation has been added that lists all of systemd's low-level
|
||||
environment variables:
|
||||
|
||||
https://github.com/systemd/systemd/blob/master/doc/ENVIRONMENT.md
|
||||
https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md
|
||||
|
||||
* sd-daemon gained a new API sd_is_socket_sockaddr() for determining
|
||||
whether a specific socket file descriptor matches a specified socket
|
||||
@ -3327,11 +3848,10 @@ CHANGES WITH 226:
|
||||
correct dequeuing of real-time signals, without losing
|
||||
signal events.
|
||||
|
||||
* When systemd requests a PolicyKit decision when managing
|
||||
units it will now add additional fields to the request,
|
||||
including unit name and desired operation. This enables more
|
||||
powerful PolicyKit policies, that make decisions depending
|
||||
on these parameters.
|
||||
* When systemd requests a polkit decision when managing units it
|
||||
will now add additional fields to the request, including unit
|
||||
name and desired operation. This enables more powerful polkit
|
||||
policies, that make decisions depending on these parameters.
|
||||
|
||||
* nspawn learnt support for .nspawn settings files, that may
|
||||
accompany the image files or directories of containers, and
|
||||
@ -3366,13 +3886,12 @@ CHANGES WITH 225:
|
||||
options and allows other programs to query the values.
|
||||
|
||||
* SELinux access control when enabling/disabling units is no
|
||||
longer enforced with this release. The previous
|
||||
implementation was incorrect, and a new corrected
|
||||
implementation is not yet available. As unit file operations
|
||||
are still protected via PolicyKit and D-Bus policy this is
|
||||
not a security problem. Yet, distributions which care about
|
||||
optimal SELinux support should probably not stabilize on
|
||||
this release.
|
||||
longer enforced with this release. The previous implementation
|
||||
was incorrect, and a new corrected implementation is not yet
|
||||
available. As unit file operations are still protected via
|
||||
polkit and D-Bus policy this is not a security problem. Yet,
|
||||
distributions which care about optimal SELinux support should
|
||||
probably not stabilize on this release.
|
||||
|
||||
* sd-bus gained support for matches of type "arg0has=", that
|
||||
test for membership of strings in string arrays sent in bus
|
||||
@ -3744,11 +4263,10 @@ CHANGES WITH 220:
|
||||
* systemd-importd gained support for verifying downloaded
|
||||
images with gpg2 (previously only gpg1 was supported).
|
||||
|
||||
* systemd-machined, systemd-logind, systemd: most bus calls
|
||||
are now accessible to unprivileged processes via
|
||||
PolicyKit. Also, systemd-logind will now allow users to kill
|
||||
their own sessions without further privileges or
|
||||
authorization.
|
||||
* systemd-machined, systemd-logind, systemd: most bus calls are
|
||||
now accessible to unprivileged processes via polkit. Also,
|
||||
systemd-logind will now allow users to kill their own sessions
|
||||
without further privileges or authorization.
|
||||
|
||||
* systemd-shutdownd has been removed. This service was
|
||||
previously responsible for implementing scheduled shutdowns
|
||||
@ -4403,7 +4921,7 @@ CHANGES WITH 217:
|
||||
/run/systemd/user directory that was already previously
|
||||
supported, but is under the control of the user.
|
||||
|
||||
* Job timeouts (i.e. time-outs on the time a job that is
|
||||
* Job timeouts (i.e. timeouts on the time a job that is
|
||||
queued stays in the run queue) can now optionally result in
|
||||
immediate reboot or power-off actions (JobTimeoutAction= and
|
||||
JobTimeoutRebootArgument=). This is useful on ".target"
|
||||
@ -4530,11 +5048,11 @@ CHANGES WITH 217:
|
||||
directly from now on, again.
|
||||
|
||||
* Support for the new ALLOW_INTERACTIVE_AUTHORIZATION D-Bus
|
||||
message flag has been added for all of systemd's PolicyKit
|
||||
authenticated method calls has been added. In particular
|
||||
this now allows optional interactive authorization via
|
||||
PolicyKit for many of PID1's privileged operations such as
|
||||
unit file enabling and disabling.
|
||||
message flag has been added for all of systemd's polkit
|
||||
authenticated method calls has been added. In particular this
|
||||
now allows optional interactive authorization via polkit for
|
||||
many of PID1's privileged operations such as unit file
|
||||
enabling and disabling.
|
||||
|
||||
* "udevadm hwdb --update" learnt a new switch "--usr" for
|
||||
placing the rebuilt hardware database in /usr instead of
|
||||
@ -4613,11 +5131,11 @@ CHANGES WITH 216:
|
||||
well as the user/group databases, which should enhance
|
||||
compatibility with certain tools like grpck.
|
||||
|
||||
* A number of bus APIs of PID 1 now optionally consult
|
||||
PolicyKit to permit access for otherwise unprivileged
|
||||
clients under certain conditions. Note that this currently
|
||||
doesn't support interactive authentication yet, but this is
|
||||
expected to be added eventually, too.
|
||||
* A number of bus APIs of PID 1 now optionally consult polkit to
|
||||
permit access for otherwise unprivileged clients under certain
|
||||
conditions. Note that this currently doesn't support
|
||||
interactive authentication yet, but this is expected to be
|
||||
added eventually, too.
|
||||
|
||||
* /etc/machine-info now has new fields for configuring the
|
||||
deployment environment of the machine, as well as the
|
||||
@ -7090,8 +7608,8 @@ CHANGES WITH 198:
|
||||
the rest of the package. It also has been updated to work
|
||||
correctly in initrds.
|
||||
|
||||
* Policykit previously has been runtime optional, and is now
|
||||
also compile time optional via a configure switch.
|
||||
* polkit previously has been runtime optional, and is now also
|
||||
compile time optional via a configure switch.
|
||||
|
||||
* systemd-analyze has been reimplemented in C. Also "systemctl
|
||||
dot" has moved into systemd-analyze.
|
||||
@ -7259,9 +7777,9 @@ CHANGES WITH 197:
|
||||
user/vendor or is automatically determined from ACPI and DMI
|
||||
information if possible.
|
||||
|
||||
* A number of PolicyKit actions are now bound together with
|
||||
"imply" rules. This should simplify creating UIs because
|
||||
many actions will now authenticate similar ones as well.
|
||||
* A number of polkit actions are now bound together with "imply"
|
||||
rules. This should simplify creating UIs because many actions
|
||||
will now authenticate similar ones as well.
|
||||
|
||||
* Unit files learnt a new condition ConditionACPower= which
|
||||
may be used to conditionalize a unit depending on whether an
|
||||
@ -7400,14 +7918,13 @@ CHANGES WITH 196:
|
||||
to maintain the necessary patches downstream, or find a
|
||||
different solution. (Talk to us if you have questions!)
|
||||
|
||||
* Various systemd components will now bypass PolicyKit checks
|
||||
for root and otherwise handle properly if PolicyKit is not
|
||||
found to be around. This should fix most issues for
|
||||
PolicyKit-less systems. Quite frankly this should have been
|
||||
this way since day one. It is absolutely our intention to
|
||||
make systemd work fine on PolicyKit-less systems, and we
|
||||
consider it a bug if something does not work as it should if
|
||||
PolicyKit is not around.
|
||||
* Various systemd components will now bypass polkit checks for
|
||||
root and otherwise handle properly if polkit is not found to
|
||||
be around. This should fix most issues for polkit-less
|
||||
systems. Quite frankly this should have been this way since
|
||||
day one. It is absolutely our intention to make systemd work
|
||||
fine on polkit-less systems, and we consider it a bug if
|
||||
something does not work as it should if polkit is not around.
|
||||
|
||||
* For embedded systems it is now possible to build udev and
|
||||
systemd without blkid and/or kmod support.
|
||||
|
||||
20
README
20
README
@ -148,12 +148,14 @@ REQUIREMENTS:
|
||||
libacl (optional)
|
||||
libselinux (optional)
|
||||
liblzma (optional)
|
||||
liblz4 >= 119 (optional)
|
||||
liblz4 >= 1.3.0 / 130 (optional)
|
||||
libgcrypt (optional)
|
||||
libqrencode (optional)
|
||||
libmicrohttpd (optional)
|
||||
libpython (optional)
|
||||
libidn2 or libidn (optional)
|
||||
gnutls >= 3.1.4 (optional, >= 3.5.3 is required to support DNS-over-TLS with gnutls)
|
||||
openssl >= 1.1.0 (optional, required to support DNS-over-TLS with openssl)
|
||||
elfutils >= 158 (optional)
|
||||
polkit (optional)
|
||||
pkg-config
|
||||
@ -161,18 +163,18 @@ REQUIREMENTS:
|
||||
docbook-xsl (optional, required for documentation)
|
||||
xsltproc (optional, required for documentation)
|
||||
python-lxml (optional, required to build the indices)
|
||||
python >= 3.4, meson >= 0.44, ninja
|
||||
python >= 3.5, meson >= 0.46, ninja
|
||||
gcc, awk, sed, grep, m4, and similar tools
|
||||
|
||||
During runtime, you need the following additional
|
||||
dependencies:
|
||||
|
||||
util-linux >= v2.27.1 required
|
||||
dbus >= 1.4.0 (strictly speaking optional, but recommended)
|
||||
dbus >= 1.9.14 (strictly speaking optional, but recommended)
|
||||
NOTE: If using dbus < 1.9.18, you should override the default
|
||||
policy directory (--with-dbuspolicydir=/etc/dbus-1/system.d).
|
||||
dracut (optional)
|
||||
PolicyKit (optional)
|
||||
polkit (optional)
|
||||
|
||||
To build in directory build/:
|
||||
meson build/ && ninja -C build
|
||||
@ -204,10 +206,12 @@ REQUIREMENTS:
|
||||
make use of DynamicUser= now, hence enabling nss-systemd is not
|
||||
optional.
|
||||
|
||||
Note that the build prefix for systemd must be /usr. -Dsplit-usr=false
|
||||
(which is the default and does not need to be specified) is the
|
||||
recommended setting, and -Dsplit-usr=true should be used on systems
|
||||
which have /usr on a separate partition.
|
||||
Note that the build prefix for systemd must be /usr. (Moreover,
|
||||
packages systemd relies on — such as D-Bus — really should use the same
|
||||
prefix, otherwise you are on your own.) -Dsplit-usr=false (which is the
|
||||
default and does not need to be specified) is the recommended setting,
|
||||
and -Dsplit-usr=true should be used on systems which have /usr on a
|
||||
separate partition.
|
||||
|
||||
Additional packages are necessary to run some tests:
|
||||
- busybox (used by test/TEST-13-NSPAWN-SMOKE)
|
||||
|
||||
16
README.md
16
README.md
@ -2,24 +2,26 @@
|
||||
|
||||
<a href="https://in.waw.pl/systemd-github-state/systemd-systemd-issues.svg"><img align="right" src="https://in.waw.pl/systemd-github-state/systemd-systemd-issues-small.svg" alt="Count of open issues over time"></a>
|
||||
<a href="https://in.waw.pl/systemd-github-state/systemd-systemd-pull-requests.svg"><img align="right" src="https://in.waw.pl/systemd-github-state/systemd-systemd-pull-requests-small.svg" alt="Count of open pull requests over time"></a>
|
||||
[](https://semaphoreci.com/systemd/systemd)<br/>
|
||||
[](https://semaphoreci.com/systemd/systemd)<br/>
|
||||
[](https://scan.coverity.com/projects/350)<br/>
|
||||
[](https://bestpractices.coreinfrastructure.org/projects/1369)<br/>
|
||||
[](https://travis-ci.org/systemd/systemd)
|
||||
[](https://travis-ci.org/systemd/systemd)<br/>
|
||||
[](https://lgtm.com/projects/g/systemd/systemd/context:cpp)<br/>
|
||||
[](https://ci.centos.org/job/systemd-pr-build/)
|
||||
|
||||
## Details
|
||||
|
||||
General information about systemd can be found in the [systemd Wiki](https://www.freedesktop.org/wiki/Software/systemd).
|
||||
|
||||
Information about build requirements are provided in the [README file](../master/README).
|
||||
Information about build requirements is provided in the [README file](README).
|
||||
|
||||
Consult our [NEWS file](../master/NEWS) for information about what's new in the most recent systemd versions.
|
||||
Consult our [NEWS file](NEWS) for information about what's new in the most recent systemd versions.
|
||||
|
||||
Please see the [HACKING file](../master/doc/HACKING) for information how to hack on systemd and test your modifications.
|
||||
Please see the [Hacking guide](docs/HACKING.md) for information on how to hack on systemd and test your modifications.
|
||||
|
||||
Please see our [Contribution Guidelines](../master/.github/CONTRIBUTING.md) for more information about filing GitHub Issues and posting GitHub Pull Requests.
|
||||
Please see our [Contribution Guidelines](docs/CONTRIBUTING.md) for more information about filing GitHub Issues and posting GitHub Pull Requests.
|
||||
|
||||
When preparing patches for systemd, please follow our [Coding Style Guidelines](../master/doc/CODING_STYLE).
|
||||
When preparing patches for systemd, please follow our [Coding Style Guidelines](docs/CODING_STYLE.md).
|
||||
|
||||
If you are looking for support, please contact our [mailing list](https://lists.freedesktop.org/mailman/listinfo/systemd-devel) or join our [IRC channel](irc://irc.freenode.org/%23systemd).
|
||||
|
||||
|
||||
211
TODO
211
TODO
@ -1,9 +1,13 @@
|
||||
Bugfixes:
|
||||
|
||||
* the error paths in usbffs_dispatch_ep() leak memory
|
||||
|
||||
* copy.c: set the right chattrs before copying files and others after
|
||||
|
||||
* Many manager configuration settings that are only applicable to user
|
||||
manager or system manager can be always set. It would be better to reject
|
||||
them when parsing config.
|
||||
|
||||
* Clarify what IPAddress* matches (source, destination, both?)
|
||||
|
||||
External:
|
||||
|
||||
* Fedora: add an rpmlint check that verifies that all unit files in the RPM are listed in %systemd_post macros.
|
||||
@ -14,16 +18,134 @@ Janitorial Clean-ups:
|
||||
|
||||
* Rearrange tests so that the various test-xyz.c match a specific src/basic/xyz.c again
|
||||
|
||||
* copy.c: set the right chattrs before copying files and others after
|
||||
|
||||
* rework mount.c and swap.c to follow proper state enumeration/deserialization
|
||||
semantics, like we do for device.c now
|
||||
|
||||
Features:
|
||||
|
||||
* the stop-when-unneded feature should be reworked: there should be a queue of
|
||||
units, and we should only enqeueu stop jobs from a defer event that processes
|
||||
queue instead of right-away when we assume that a unit is now unneeded.
|
||||
* make MAINPID= message reception checks even stricter: if service uses User=,
|
||||
then check sending UID and ignore message if it doesn't match the user or
|
||||
root.
|
||||
|
||||
* maybe trigger a uevent "change" on a device if "systemctl reload xyz.device"
|
||||
is issued.
|
||||
|
||||
* when importing an fs tree with machined, optionally apply userns-rec-chown
|
||||
|
||||
* when importing an fs tree with machined, complain if image is not an OS
|
||||
|
||||
* Maybe introduce a helper safe_exec() or so, which is to execve() which
|
||||
safe_fork() is to fork(). And then make revert the RLIMIT_NOFILE soft limit
|
||||
to 1K implicitly, unless explicitly opted-out.
|
||||
|
||||
* rework seccomp/nnp logic that that even if User= is used in combination with
|
||||
a seccomp option we don't have to set NNP. For that, change uid first whil
|
||||
keeping CAP_SYS_ADMIN, then apply seccomp, the drop cap.
|
||||
|
||||
* add a concept for automatically loading per-unit secrets off disk and
|
||||
inserting them into the kernel keyring. Maybe SecretsDirectory= similar to
|
||||
ConfigurationDirectory=.
|
||||
|
||||
* when no locale is configured, default to UEFI's PlatformLang variable
|
||||
|
||||
* When logind.conf contains HandleLidSwitch=suspend-then-hibernate and we can't
|
||||
hibernate because the swap partition isn't large enough, still suspend
|
||||
|
||||
* bootctl: implement Type #2 boot loader entry discovery
|
||||
|
||||
* bootctl,sd-boot: actually honour the "architecture" key
|
||||
|
||||
* when a socket unit is spawned with an AF_UNIX path in /var/run, complain and
|
||||
patch it to use /run instead
|
||||
|
||||
* set memory.oom.group in cgroupsv2 for all leaf cgroups (kernel v4.19+)
|
||||
|
||||
* add a new syscall group "@esoteric" for more esoteric stuff such as bpf() and
|
||||
usefaultd() and make systemd-analyze check for it.
|
||||
|
||||
* paranoia: whenever we process passwords, call mlock() on the memory
|
||||
first. i.e. look for all places we use string_erase()/string_free_erase() and
|
||||
augment them with mlock()
|
||||
|
||||
* whenever oom_kill memory.event event is triggered print a nice log message
|
||||
|
||||
* Move RestrictAddressFamily= to the new cgroup create socket
|
||||
|
||||
* support the bind/connect/sendmsg cgroup stuff for sandboxing, and possibly
|
||||
patching around
|
||||
|
||||
* maybe implicitly attach monotonic+realtime timestamps to outgoing messages in
|
||||
log.c and sd-journal-send
|
||||
|
||||
* chown() tty a service is attached to after the service goes down
|
||||
|
||||
* optionally: turn on cgroup delegation for per-session scope units
|
||||
|
||||
* introduce per-unit (i.e. per-slice, per-service) journal log size limits.
|
||||
|
||||
* optionally, if a per-partition GPT flag is set for the root/home/… partitions
|
||||
format the partition on next boot and unset the flag, in order to implement
|
||||
factory reset. also, add a second flag that simply indicates whether such a
|
||||
scheme is supported. then, add a tool (or maybe beef up systemd-dissect) to
|
||||
show state of these flags, and optionally trigger such a factory reset on
|
||||
next boot by setting the flag.
|
||||
|
||||
* sd-boot: search drop-ins in $BOOT, too
|
||||
|
||||
* sd-boot: add "oneshot boot timeout" variable support
|
||||
|
||||
* sd-boot: automatically load EFI modules from some drop-in dir, so that people
|
||||
can add in file system drivers and such
|
||||
|
||||
* esp generator: also mount $BOOT if found
|
||||
|
||||
* sd-boot: optionally, show boot menu when previous default boot item has
|
||||
non-zero "tries done" count
|
||||
|
||||
* logind: add "boot into bootmenu" API, and possibly even "boot into windows"
|
||||
and "boot into macos".
|
||||
|
||||
* bootspec.c: also enumerate EFI unified kernel images.
|
||||
|
||||
* maybe set a special xattr on cgroups that have delegate=yes set, to make it
|
||||
easy to mark cut points
|
||||
|
||||
* introduce an option (or replacement) for "systemctl show" that outputs all
|
||||
properties as JSON, similar to busctl's new JSON output. In contrast to that
|
||||
it should skip the variant type string though.
|
||||
|
||||
* augment CODE_FILE=, CODE_LINE= with something like CODE_BASE= or so which
|
||||
contains some identifier for the project, which allows us to include
|
||||
clickable links to source files generating these log messages. The identifier
|
||||
could be some abberviated URL prefix or so (taking inspiration from Go
|
||||
imports). For example, for systemd we could use
|
||||
CODE_BASE=github.com/systemd/systemd/blob/98b0b1123cc or so which is
|
||||
sufficient to build a link by prefixing "http://" and suffixing the
|
||||
CODE_FILE.
|
||||
|
||||
* when outputting log data with journalctl and the log data includes references
|
||||
to configuration files (CONFIG_FILE=), create a clickable link for it.
|
||||
|
||||
* Augment MESSAGE_ID with MESSAGE_BASE, in a similar fashion so that we can
|
||||
make clickable links from log messages carrying a MESSAGE_ID, that lead to
|
||||
some explanatory text online.
|
||||
|
||||
* maybe extend .path units to expose fanotify() per-mount change events
|
||||
|
||||
* Add a "systemctl list-units --by-slice" mode or so, which rearranges the
|
||||
output of "systemctl list-units" slightly by showing the tree structure of
|
||||
the slices, and the units attached to them.
|
||||
|
||||
* the a-posteriori stopping of units bound to units that disappeared logic
|
||||
should be reworked: there should be a queue of units, and we should only
|
||||
enqeue stop jobs from a defer event that processes queue instead of
|
||||
right-away when we find a unit that is bound to one that doesn't exist
|
||||
anymore. (similar to how the stop-unneeded queue has been reworked the same
|
||||
way)
|
||||
|
||||
* nspawn: make nspawn suitable for shell pipelines: instead of triggering a
|
||||
hangup when input is finished, send ^D, which synthesizes an EOF. Then wait
|
||||
for hangup or ^D before passing on the EOF.
|
||||
|
||||
* When reloading configuration PID 1 should reset all its properties to the
|
||||
original defaults before calling parse_config()
|
||||
@ -33,15 +155,13 @@ Features:
|
||||
|
||||
* nspawn: greater control over selinux label?
|
||||
|
||||
* cgroups: figure out if we can somehow communicate in a cleaner way whether a
|
||||
systemd instance not running in the cgroup root shall or shall not manage the
|
||||
attributes of its top-level cgroup. Currently it assumes it manages all, but
|
||||
then might get EPERM due to permission porblems/userns, which is OK, but this
|
||||
should be revisited to make clearer and also work if the payload systemd runs
|
||||
with full privs and without userns.
|
||||
* hibernate/s2h: make this robust and safe to enable in Fedora by default.
|
||||
Specifically:
|
||||
|
||||
* portables: introduce a new unit file directory /etc/systemd/system.attached/
|
||||
or so, where we attach portable services to
|
||||
1. add resume_offset support to the resume code (i.e. support swap files
|
||||
properly)
|
||||
2. check if swap is on weird storage and refuse if so
|
||||
3. add autodetection of hibernation images
|
||||
|
||||
* cgroups: use inotify to get notified when somebody else modifies cgroups
|
||||
owned by us, then log a friendly warning.
|
||||
@ -51,10 +171,6 @@ Features:
|
||||
that our log messages could contain clickable links for example for unit
|
||||
files and suchlike we operate on.
|
||||
|
||||
* introduce a new SystemCallFilters= group called "@system-service" with a
|
||||
sensible default set for system services, then make use of them in portable
|
||||
profiles
|
||||
|
||||
* add support for "portablectl attach http://foobar.com/waaa.raw (i.e. importd integration)
|
||||
|
||||
* add attach --enable and attach --now (for attach+enable+start)
|
||||
@ -73,7 +189,7 @@ Features:
|
||||
zero and is not open anymore, while the latter happens when a file is
|
||||
unlinked from any dir.
|
||||
|
||||
* port systemctl, systemd-inhibit, busctl, … over to format-table.[ch]'s table formatters
|
||||
* port systemctl, busctl, … over to format-table.[ch]'s table formatters
|
||||
|
||||
* pid1: lock image configured with RootDirectory=/RootImage= using the usual nspawn semantics while the unit is up
|
||||
|
||||
@ -130,13 +246,6 @@ Features:
|
||||
* calenderspec: add support for week numbers and day numbers within a
|
||||
year. This would allow us to define "bi-weekly" triggers safely.
|
||||
|
||||
* add bpf-based implementation of devices cgroup controller logic for compat
|
||||
with cgroupsv2 as supported by newest kernel
|
||||
|
||||
* introduce sd_id128_get_boot_app_specific() which is like
|
||||
sd_id128_get_machine_app_specific(). After all on long-running systems both
|
||||
IDs have similar properties.
|
||||
|
||||
* sd-bus: add vtable flag, that may be used to request client creds implicitly
|
||||
and asynchronously before dispatching the operation
|
||||
|
||||
@ -151,14 +260,13 @@ Features:
|
||||
|
||||
* taint systemd if there are fewer than 65536 users assigned (userns) to the system.
|
||||
|
||||
* deprecate PermissionsStartOnly= and RootDirectoryStartOnly= in favour of the ExecStart= prefix chars
|
||||
* deprecate RootDirectoryStartOnly= in favour of a new ExecStart= prefix char
|
||||
|
||||
* add a new RuntimeDirectoryPreserve= mode that defines a similar lifecycle for
|
||||
the runtime dir as we maintain for the fdstore: i.e. keep it around as long
|
||||
as the unit is running or has a job queued.
|
||||
|
||||
* support projid-based quota in machinectl for containers, and then drop
|
||||
implicit btrfs loopback magic in machined
|
||||
* support projid-based quota in machinectl for containers
|
||||
|
||||
* Add NetworkNamespacePath= to specify a path to a network namespace
|
||||
|
||||
@ -187,9 +295,6 @@ Features:
|
||||
* beef up pam_systemd to take unit file settings such as cgroups properties as
|
||||
parameters
|
||||
|
||||
* a new "systemd-analyze security" tool outputting a checklist of security
|
||||
features a service does and does not implement
|
||||
|
||||
* maybe hook of xfs/ext4 quotactl() with services? i.e. automatically manage
|
||||
the quota of a the user indicated in User= via unit file settings, like the
|
||||
other resource management concepts. Would mix nicely with DynamicUser=1. Or
|
||||
@ -198,11 +303,6 @@ Features:
|
||||
StateDirectory=, LogsDirectory=, CacheDirectory=, as well as RootDirectory= if it
|
||||
is set, plus the whole disk space any image configured with RootImage=.
|
||||
|
||||
* Introduce "exit" as an EmergencyAction value, and allow to configure a
|
||||
per-unit success/failure exit code to configure. This would be useful for
|
||||
running commands inside of services inside of containers, which could then
|
||||
propagate their failure state all the way up.
|
||||
|
||||
* In DynamicUser= mode: before selecting a UID, use disk quota APIs on relevant
|
||||
disks to see if the UID is already in use.
|
||||
|
||||
@ -210,15 +310,6 @@ Features:
|
||||
for all units. It should be both a way to pin units into memory as well as a
|
||||
wait to retrieve their exit data.
|
||||
|
||||
* maybe set a new set of env vars for services, based on RuntimeDirectory=,
|
||||
StateDirectory=, LogsDirectory=, CacheDirectory= and ConfigurationDirectory=
|
||||
automatically. For example, there could be $RUNTIME_DIRECTORY,
|
||||
$STATE_DIRECTORY, $LOGS_DIRECTORY=, $CACHE_DIRECTORY and
|
||||
$CONFIGURATION_DIRECTORY or so. This could be useful to write services that
|
||||
can adapt to varying directories for these purposes. Special care has to be
|
||||
taken if multiple dirs are configured. Maybe avoid setting the env vars in
|
||||
that case?
|
||||
|
||||
* expose IO accounting data on the bus, show it in systemd-run --wait and log
|
||||
about it in the resource log message
|
||||
|
||||
@ -228,7 +319,7 @@ Features:
|
||||
* show whether a service has out-of-date configuration in "systemctl status" by
|
||||
using mtime data of ConfigurationDirectory=.
|
||||
|
||||
* replace all uses of fgets() + LINE_MAX by read_line()
|
||||
* replace all remaining uses of fgets() + LINE_MAX by read_line()
|
||||
|
||||
* Add AddUser= setting to unit files, similar to DynamicUser=1 which however
|
||||
creates a static, persistent user rather than a dynamic, transient user. We
|
||||
@ -326,8 +417,6 @@ Features:
|
||||
on PID 1 with the relevant signals, and makes relevant files in /sys and
|
||||
/proc (such as the sysrq stuff) unavailable
|
||||
|
||||
* DeviceAllow= should also generate seccomp filters for mknod()
|
||||
|
||||
* make sure the ratelimit object can deal with USEC_INFINITY as way to turn off things
|
||||
|
||||
* journalctl: make sure -f ends when the container indicated by -M terminates
|
||||
@ -396,9 +485,6 @@ Features:
|
||||
state.
|
||||
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030229.html
|
||||
|
||||
* Maybe add support for the equivalent of "ethtool advertise" to .link files?
|
||||
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030112.html
|
||||
|
||||
* The udev blkid built-in should expose a property that reflects
|
||||
whether media was sensed in USB CF/SD card readers. This should then
|
||||
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
|
||||
@ -410,8 +496,6 @@ Features:
|
||||
|
||||
* hostnamectl: show root image uuid
|
||||
|
||||
* sysfs set api in libudev is not const
|
||||
|
||||
* Find a solution for SMACK capabilities stuff:
|
||||
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026188.html
|
||||
|
||||
@ -439,8 +523,6 @@ Features:
|
||||
|
||||
* maybe add support for specifier expansion in user.conf, specifically DefaultEnvironment=
|
||||
|
||||
* introduce systemd-timesync-wait.service or so to sync on an NTP fix?
|
||||
|
||||
* consider showing the unit names during boot up in the status output, not just the unit descriptions
|
||||
|
||||
* maybe allow timer units with an empty Units= setting, so that they
|
||||
@ -528,7 +610,6 @@ Features:
|
||||
|
||||
* cgroups:
|
||||
- implement per-slice CPUFairScheduling=1 switch
|
||||
- handle jointly mounted controllers correctly
|
||||
- introduce high-level settings for RT budget, swappiness
|
||||
- how to reset dynamically changed unit cgroup attributes sanely?
|
||||
- when reloading configuration, apply new cgroup configuration
|
||||
@ -582,7 +663,6 @@ Features:
|
||||
- document chaining of signal handler for SIGCHLD and child handlers
|
||||
- define more intervals where we will shift wakeup intervals around in, 1h, 6h, 24h, ...
|
||||
- generate a failure of a default event loop is executed out-of-thread
|
||||
- maybe add support for inotify events (which we can do safely now, with O_PATH)
|
||||
|
||||
* investigate endianness issues of UUID vs. GUID
|
||||
|
||||
@ -593,8 +673,6 @@ Features:
|
||||
|
||||
* add a pam module that on password changes updates any LUKS slot where the password matches
|
||||
|
||||
* maybe add a generator that looks for "systemd.run=" on the kernel cmdline for container usercases...
|
||||
|
||||
* test/:
|
||||
- add unit tests for config_parse_device_allow()
|
||||
|
||||
@ -641,11 +719,9 @@ Features:
|
||||
|
||||
* logind:
|
||||
- logind: optionally, ignore idle-hint logic for autosuspend, block suspend as long as a session is around
|
||||
- When we update the kernel all kind of hibernation should be prohibited until shutdown/reboot
|
||||
- logind: wakelock/opportunistic suspend support
|
||||
- Add pretty name for seats in logind
|
||||
- logind: allow showing logout dialog from system?
|
||||
- session scopes/user unit: add RequiresMountsFor for the home directory of the user
|
||||
- add Suspend() bus calls which take timestamps to fix double suspend issues when somebody hits suspend and closes laptop quickly.
|
||||
- if pam_systemd is invoked by su from a process that is outside of a
|
||||
any session we should probably just become a NOP, since that's
|
||||
@ -802,8 +878,6 @@ Features:
|
||||
PID 1...
|
||||
- optionally automatically add FORWARD rules to iptables whenever nspawn is
|
||||
running, remove them when shut down.
|
||||
- maybe make copying of /etc/resolv.conf optional, and skip it if --read-only
|
||||
is used
|
||||
|
||||
* dissect
|
||||
- refuse mounting over a mount point
|
||||
@ -818,16 +892,11 @@ Features:
|
||||
"machinectl start" with a new --ephemeral switch
|
||||
- "machinectl status" should also show internal logs of the container in
|
||||
question
|
||||
- "machinectl list-images" should show os-release data, as well as
|
||||
machine-info data (including deployment level)
|
||||
- "machinectl history"
|
||||
- "machinectl diff"
|
||||
- "machinectl commit" that takes a writable snapshot of a tree, invokes a
|
||||
shell in it, and marks it read-only after use
|
||||
|
||||
* importd:
|
||||
- generate a nice warning if mkfs.btrfs is missing
|
||||
|
||||
* cryptsetup:
|
||||
- cryptsetup-generator: allow specification of passwords in crypttab itself
|
||||
- support rd.luks.allow-discards= kernel cmdline params in cryptsetup generator
|
||||
@ -1015,8 +1084,6 @@ External:
|
||||
|
||||
* kernel: add device_type = "fb", "fbcon" to class "graphics"
|
||||
|
||||
* drop accountsservice's StandardOutput=syslog and Type=dbus fields
|
||||
|
||||
* /usr/bin/service should actually show the new command line
|
||||
|
||||
* fedora: suggest auto-restart on failure, but not on success and not on coredump. also, ask people to think about changing the start limit logic. Also point people to RestartPreventExitStatus=, SuccessExitStatus=
|
||||
|
||||
@ -17,7 +17,6 @@ in_files = '''
|
||||
|
||||
support_url = get_option('support-url')
|
||||
support_sed = 's~%SUPPORT_URL%~@0@~'.format(support_url)
|
||||
build_catalog_dir = meson.current_build_dir()
|
||||
|
||||
foreach file : in_files
|
||||
custom_target(
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
# SPDX-License-Identifier: LGPL-2.1+
|
||||
#
|
||||
# Copyright © 2015, 2016 Viktar Vaŭčkievič
|
||||
|
||||
# Message catalog for systemd's own messages
|
||||
# Belarusian translation
|
||||
|
||||
@ -175,7 +173,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Працэс запуску юніта @UNIT@ завершаны.
|
||||
|
||||
Вынік: @RESULT@.
|
||||
Вынік: @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Юніт @UNIT@ спыняецца
|
||||
@ -198,7 +196,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Збой юніта @UNIT@.
|
||||
|
||||
Вынік: @RESULT@.
|
||||
Вынік: @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Юніт @UNIT@ перачытвае сваю канфігурацыю
|
||||
@ -214,7 +212,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Юніт @UNIT@ перачытаў сваю канфігурацыю.
|
||||
|
||||
Вынік: @RESULT@.
|
||||
Вынік: @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Працэс @EXECUTABLE@ не можа быць выкананы
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
# SPDX-License-Identifier: LGPL-2.1+
|
||||
#
|
||||
# Copyright © 2015, 2016 Viktar Vaŭčkievič
|
||||
|
||||
# Message catalog for systemd's own messages
|
||||
# Belarusian Latin translation
|
||||
|
||||
@ -178,7 +176,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Praces zapusku junita @UNIT@ zavieršany.
|
||||
|
||||
Vynik: @RESULT@.
|
||||
Vynik: @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Junit @UNIT@ spyniajecca
|
||||
@ -201,7 +199,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Zboj junita @UNIT@.
|
||||
|
||||
Vynik: @RESULT@.
|
||||
Vynik: @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Junit @UNIT@ pieračytvaje svaju kanfihuracyju
|
||||
@ -217,7 +215,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Junit @UNIT@ pieračytaŭ svaju kanfihuracyju.
|
||||
|
||||
Vynik: @RESULT@.
|
||||
Vynik: @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Praces @EXECUTABLE@ nie moža być vykanany
|
||||
|
||||
@ -178,7 +178,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Стартирането на модул „@UNIT@“ завърши.
|
||||
|
||||
Резултатът е: @RESULT@
|
||||
Резултатът е: @JOB_RESULT@
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Модул „@UNIT@“ се спира
|
||||
@ -201,7 +201,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Модулът „@UNIT@“ не успя да стартира.
|
||||
|
||||
Резултатът е: @RESULT@
|
||||
Резултатът е: @JOB_RESULT@
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Модулът „@UNIT@“ започна презареждане на настройките си
|
||||
@ -217,7 +217,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Модулът „@UNIT@“ завърши презареждането на настройките си.
|
||||
|
||||
Резултатът e: @RESULT@
|
||||
Резултатът e: @JOB_RESULT@
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Програмата „@EXECUTABLE@“ не успя да се стартира
|
||||
|
||||
@ -52,7 +52,8 @@ dropped, other services' messages are unaffected.
|
||||
|
||||
The limits controlling when messages are dropped may be configured
|
||||
with RateLimitIntervalSec= and RateLimitBurst= in
|
||||
/etc/systemd/journald.conf. See journald.conf(5) for details.
|
||||
/etc/systemd/journald.conf or LogRateLimitIntervalSec= and LogRateLimitBurst=
|
||||
in the unit file. See journald.conf(5) and systemd.exec(5) for details.
|
||||
|
||||
-- e9bf28e6e834481bb6f48f548ad13606
|
||||
Subject: Journal messages have been missed
|
||||
@ -188,59 +189,67 @@ System shutdown has been initiated. The shutdown has now begun and
|
||||
all system services are terminated and all file systems unmounted.
|
||||
|
||||
-- 7d4958e842da4a758f6c1cdc7b36dcc5
|
||||
Subject: Unit @UNIT@ has begun start-up
|
||||
Subject: A start job for unit @UNIT@ has begun execution
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has begun starting up.
|
||||
A start job for unit @UNIT@ has begun execution.
|
||||
|
||||
The job identifier is @JOB_ID@.
|
||||
|
||||
-- 39f53479d3a045ac8e11786248231fbf
|
||||
Subject: Unit @UNIT@ has finished start-up
|
||||
Subject: A start job for unit @UNIT@ has finished successfully
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has finished starting up.
|
||||
A start job for unit @UNIT@ has finished successfully.
|
||||
|
||||
The start-up result is @RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Unit @UNIT@ has begun shutting down
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has begun shutting down.
|
||||
|
||||
-- 9d1aaa27d60140bd96365438aad20286
|
||||
Subject: Unit @UNIT@ has finished shutting down
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has finished shutting down.
|
||||
The job identifier is @JOB_ID@.
|
||||
|
||||
-- be02cf6855d2428ba40df7e9d022f03d
|
||||
Subject: Unit @UNIT@ has failed
|
||||
Subject: A start job for unit @UNIT@ has failed
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has failed.
|
||||
A start job for unit @UNIT@ has finished with a failure.
|
||||
|
||||
The result is @RESULT@.
|
||||
The job identifier is @JOB_ID@ and the job result is @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: A stop job for unit @UNIT@ has begun execution
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
A stop job for unit @UNIT@ has begun execution.
|
||||
|
||||
The job identifier is @JOB_ID@.
|
||||
|
||||
-- 9d1aaa27d60140bd96365438aad20286
|
||||
Subject: A stop job for unit @UNIT@ has finished
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
A stop job for unit @UNIT@ has finished.
|
||||
|
||||
The job identifier is @JOB_ID@ and the job result is @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Unit @UNIT@ has begun reloading its configuration
|
||||
Subject: A reload job for unit @UNIT@ has begun execution
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has begun reloading its configuration
|
||||
A reload job for unit @UNIT@ has begun execution.
|
||||
|
||||
The job identifier is @JOB_ID@.
|
||||
|
||||
-- 7b05ebc668384222baa8881179cfda54
|
||||
Subject: Unit @UNIT@ has finished reloading its configuration
|
||||
Subject: A reload job for unit @UNIT@ has finished
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Unit @UNIT@ has finished reloading its configuration
|
||||
A reload job for unit @UNIT@ has finished.
|
||||
|
||||
The result is @RESULT@.
|
||||
The job identifier is @JOB_ID@ and the job result is @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Process @EXECUTABLE@ could not be executed
|
||||
@ -343,6 +352,29 @@ Support: %SUPPORT_URL%
|
||||
|
||||
The unit @UNIT@ completed and consumed the indicated resources.
|
||||
|
||||
-- 7ad2d189f7e94e70a38c781354912448
|
||||
Subject: Unit succeeded
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
The unit @UNIT@ has successfully entered the 'dead' state.
|
||||
|
||||
-- d9b373ed55a64feb8242e02dbe79a49c
|
||||
Subject: Unit failed
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
The unit @UNIT@ has entered the 'failed' state with result '@UNIT_RESULT@'.
|
||||
|
||||
-- 98e322203f7a4ed290d09fe03c09fe15
|
||||
Subject: Unit process exited
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
An @COMMAND@= process belonging to unit @UNIT@ has exited.
|
||||
|
||||
The process' exit code is '@EXIT_CODE@' and its exit status is @EXIT_STATUS@.
|
||||
|
||||
-- 50876a9db00f4c40bde1a2ad381c3a1b
|
||||
Subject: The system is configured in a way that might cause problems
|
||||
Defined-By: systemd
|
||||
|
||||
@ -159,7 +159,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Enhed @UNIT@ er færdig med at starte op.
|
||||
|
||||
Resultat for opstart er @RESULT@.
|
||||
Resultat for opstart er @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Enhed @UNIT@ har påbegyndt nedlukning
|
||||
@ -182,7 +182,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Enhed @UNIT@ har fejlet.
|
||||
|
||||
Resultatet er @RESULT@
|
||||
Resultatet er @JOB_RESULT@
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Enhed @UNIT@ har påbegyndt genindlæsning af sin konfiguration
|
||||
@ -198,7 +198,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Enhed @UNIT@ er færdig med at genindlæse sin konfiguration
|
||||
|
||||
Resultatet er: @RESULT@.
|
||||
Resultatet er: @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Process @EXECUTABLE@ kunne ikke eksekveres
|
||||
|
||||
@ -191,7 +191,7 @@ Subject: L'unité (unit) @UNIT@ a terminé son démarrage
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
L'unité (unit) @UNIT@ a terminé son démarrage, avec le résultat @RESULT@.
|
||||
L'unité (unit) @UNIT@ a terminé son démarrage, avec le résultat @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: L'unité (unit) @UNIT@ a commencé à s'arrêter
|
||||
@ -212,7 +212,7 @@ Subject: L'unité (unit) @UNIT@ a échoué
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
L'unité (unit) @UNIT@ a échoué, avec le résultat @RESULT@.
|
||||
L'unité (unit) @UNIT@ a échoué, avec le résultat @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: L'unité (unit) @UNIT@ a commencé à recharger sa configuration
|
||||
@ -227,7 +227,7 @@ Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
L'unité (unit) @UNIT@ a terminé de recharger configuration,
|
||||
avec le résultat @RESULT@.
|
||||
avec le résultat @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Le processus @EXECUTABLE@ n'a pas pu être exécuté
|
||||
|
||||
@ -173,7 +173,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Jedinica @UNIT@ je završila pokretanje.
|
||||
|
||||
Rezultat pokretanja je @RESULT@.
|
||||
Rezultat pokretanja je @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Jedinica @UNIT@ je započela isključivanje
|
||||
@ -196,7 +196,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Jedinica @UNIT@ nije uspjela.
|
||||
|
||||
Rezultat je @RESULT@.
|
||||
Rezultat je @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Jedinica @UNIT@ je započela ponovno učitavati podešavanja
|
||||
@ -212,7 +212,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Jedinica @UNIT@ je završila ponovno učitavati podešavanja
|
||||
|
||||
Rezultat je @RESULT@.
|
||||
Rezultat je @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Proces @EXECUTABLE@ se ne može pokrenuti
|
||||
|
||||
@ -161,7 +161,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
A(z) @UNIT@ egység befejezte az indulást
|
||||
|
||||
Az indítás eredménye: @RESULT@.
|
||||
Az indítás eredménye: @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: A(z) @UNIT@ egység megkezdte a leállást
|
||||
@ -184,7 +184,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
A(z) @UNIT@ egység hibát jelzett.
|
||||
|
||||
Az eredmény: @RESULT@.
|
||||
Az eredmény: @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: A(z) @UNIT@ egység megkezdte a beállításainak újratöltését
|
||||
@ -200,7 +200,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
A(z) @UNIT@ egység befejezte a beállításainak újratöltését.
|
||||
|
||||
Az eredmény: @RESULT@.
|
||||
Az eredmény: @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: A folyamat végrehajtása sikertelen: @EXECUTABLE@
|
||||
|
||||
@ -191,7 +191,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
L'unità @UNIT@ ha terminato la fase di avvio.
|
||||
|
||||
La fase di avvio è @RESULT@.
|
||||
La fase di avvio è @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: L'unità @UNIT@ inizia la fase di spegnimento
|
||||
@ -214,7 +214,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
L'unità @UNIT@ è fallita.
|
||||
|
||||
Il risultato è @RESULT@.
|
||||
Il risultato è @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: L'unità @UNIT@ inizia a caricare la propria configurazione
|
||||
@ -230,7 +230,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
L'unità @UNIT@ è terminata ricaricando la propria configurazione
|
||||
|
||||
Il risultato è @RESULT@.
|
||||
Il risultato è @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Il processo @EXECUTABLE@ non può essere eseguito
|
||||
|
||||
@ -182,7 +182,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
@UNIT@ 유닛 시동을 마쳤습니다.
|
||||
|
||||
시동 결과는 @RESULT@ 입니다.
|
||||
시동 결과는 @JOB_RESULT@ 입니다.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: @UNIT@ 유닛 끝내기 동작 시작
|
||||
@ -205,7 +205,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
@UNIT@ 유닛 동작에 실패했습니다.
|
||||
|
||||
결과는 @RESULT@ 입니다.
|
||||
결과는 @JOB_RESULT@ 입니다.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: @UNIT@ 유닛 설정 다시 읽기 시작
|
||||
@ -221,7 +221,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
@UNIT@ 유닛의 설정 다시 읽기 동작을 끝냈습니다.
|
||||
|
||||
결과는 @RESULT@ 입니다.
|
||||
결과는 @JOB_RESULT@ 입니다.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: @EXECUTABLE@ 프로세스 시작할 수 없음
|
||||
|
||||
@ -1,6 +1,4 @@
|
||||
# SPDX-License-Identifier: LGPL-2.1+
|
||||
#
|
||||
# Copyright © 2014-2017 Piotr Drąg
|
||||
|
||||
# Message catalog for systemd's own messages
|
||||
# Polish translation
|
||||
@ -56,7 +54,9 @@ Nie ma to wpływu na komunikaty innych usług.
|
||||
|
||||
Ograniczenia kontrolujące pomijanie komunikatów mogą być konfigurowane
|
||||
za pomocą opcji RateLimitIntervalSec= i RateLimitBurst= w pliku
|
||||
/etc/systemd/journald.conf. Strona journald.conf(5) zawiera więcej informacji.
|
||||
/etc/systemd/journald.conf lub LogRateLimitIntervalSec= i LogRateLimitBurst=
|
||||
w pliku jednostki. Strony journald.conf(5) i systemd.exec(5) zawierają więcej
|
||||
informacji.
|
||||
|
||||
-- e9bf28e6e834481bb6f48f548ad13606
|
||||
Subject: Utracono komunikaty dziennika
|
||||
@ -188,59 +188,67 @@ Zainicjowano wyłączenie systemu. Wyłączenie zostało rozpoczęte i wszystki
|
||||
usługi systemowe zostały zakończone, a wszystkie systemy plików odmontowane.
|
||||
|
||||
-- 7d4958e842da4a758f6c1cdc7b36dcc5
|
||||
Subject: Rozpoczęto uruchamianie jednostki @UNIT@
|
||||
Subject: Rozpoczęto wykonywanie zadania uruchamiania dla jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ rozpoczęła uruchamianie.
|
||||
Rozpoczęto wykonywanie zadania uruchamiania dla jednostki @UNIT@.
|
||||
|
||||
Identyfikator zadania: @JOB_ID@.
|
||||
|
||||
-- 39f53479d3a045ac8e11786248231fbf
|
||||
Subject: Ukończono uruchamianie jednostki @UNIT@
|
||||
Subject: Pomyślnie ukończono zadanie uruchamiania dla jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ ukończyła uruchamianie.
|
||||
Pomyślnie ukończono zadanie uruchamiania dla jednostki @UNIT@.
|
||||
|
||||
Wynik uruchamiania: @RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Rozpoczęto wyłączanie jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ rozpoczęła wyłączanie.
|
||||
|
||||
-- 9d1aaa27d60140bd96365438aad20286
|
||||
Subject: Ukończono wyłączanie jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ ukończyła wyłączanie.
|
||||
Identyfikator zadania: @JOB_ID@.
|
||||
|
||||
-- be02cf6855d2428ba40df7e9d022f03d
|
||||
Subject: Jednostka @UNIT@ się nie powiodła
|
||||
Subject: Zadanie uruchamiania dla jednostki @UNIT@ się nie powiodło
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ się nie powiodła.
|
||||
Zadanie uruchamiania dla jednostki @UNIT@ zostało ukończone z niepowodzeniem.
|
||||
|
||||
Wynik: @RESULT@.
|
||||
Identyfikator zadania: @JOB_ID@, wynik zadania: @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Rozpoczęto wykonywanie zadania zatrzymania dla jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Rozpoczęto wykonywanie zadania zatrzymania dla jednostki @UNIT@.
|
||||
|
||||
Identyfikator zadania: @JOB_ID@.
|
||||
|
||||
-- 9d1aaa27d60140bd96365438aad20286
|
||||
Subject: Ukończono zadanie zatrzymania dla jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Ukończono zadanie zatrzymania dla jednostki @UNIT@.
|
||||
|
||||
Identyfikator zadania: @JOB_ID@, wynik zadania: @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Rozpoczęto ponowne wczytywanie konfiguracji jednostki @UNIT@
|
||||
Subject: Rozpoczęto wykonywanie zadania ponownego wczytania dla jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ rozpoczęła ponowne wczytywanie swojej konfiguracji.
|
||||
Rozpoczęto wykonywanie zadania ponownego wczytania dla jednostki @UNIT@.
|
||||
|
||||
Identyfikator zadania: @JOB_ID@.
|
||||
|
||||
-- 7b05ebc668384222baa8881179cfda54
|
||||
Subject: Ukończono ponowne wczytywanie konfiguracji jednostki @UNIT@
|
||||
Subject: Ukończono zadanie ponownego wczytania dla jednostki @UNIT@
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ ukończyła ponowne wczytywanie swojej konfiguracji.
|
||||
Ukończono zadanie ponownego wczytania dla jednostki @UNIT@.
|
||||
|
||||
Wynik: @RESULT@.
|
||||
Identyfikator zadania: @JOB_ID@, wynik zadania: @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Nie można wykonać procesu @EXECUTABLE@
|
||||
@ -338,6 +346,30 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ została ukończona, zużywając wskazane zasoby.
|
||||
|
||||
-- 7ad2d189f7e94e70a38c781354912448
|
||||
Subject: Jednostka się powiodła
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ pomyślnie przeszła do stanu „dead” (martwego).
|
||||
|
||||
-- d9b373ed55a64feb8242e02dbe79a49c
|
||||
Subject: Jednostka się nie powiodła
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Jednostka @UNIT@ przeszła do stanu „failed” (niepowodzenia)
|
||||
z wynikiem „@UNIT_RESULT@”.
|
||||
|
||||
-- 98e322203f7a4ed290d09fe03c09fe15
|
||||
Subject: Proces jednostki zakończył działanie
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
Proces @COMMAND@= należący do jednostki @UNIT@ zakończył działanie.
|
||||
|
||||
Kod wyjścia procesu: „@EXIT_CODE@”, jego stan wyjścia: @EXIT_STATUS@.
|
||||
|
||||
-- 50876a9db00f4c40bde1a2ad381c3a1b
|
||||
Subject: System jest skonfigurowany w sposób, który może powodować problemy
|
||||
Defined-By: systemd
|
||||
|
||||
@ -162,7 +162,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
A unidade @UNIT@ concluiu a inicialização.
|
||||
|
||||
The start-up result is @RESULT@.
|
||||
The start-up result is @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Unidade @UNIT@ sendo desligado
|
||||
@ -185,7 +185,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
A unidade @UNIT@ falhou.
|
||||
|
||||
O resultado é @RESULT@.
|
||||
O resultado é @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Unidade @UNIT@ iniciou recarregamento de sua configuração
|
||||
@ -201,7 +201,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
A unidade @UNIT@ concluiu o recarregamento de sua configuração.
|
||||
|
||||
O resultado é @RESULT@.
|
||||
O resultado é @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Processo @EXECUTABLE@ não pôde ser executado
|
||||
|
||||
@ -227,7 +227,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Процесс запуска юнита @UNIT@ был завершен.
|
||||
|
||||
Результат: @RESULT@.
|
||||
Результат: @JOB_RESULT@.
|
||||
|
||||
# Subject: Unit @UNIT@ has begun shutting down
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
@ -253,7 +253,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Произошел сбой юнита @UNIT@.
|
||||
|
||||
Результат: @RESULT@.
|
||||
Результат: @JOB_RESULT@.
|
||||
|
||||
# Subject: Unit @UNIT@ has begun with reloading its configuration
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
@ -271,7 +271,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Юнит @UNIT@ завершил процесс перечитывания своей конфигурации.
|
||||
|
||||
Результат: @RESULT@.
|
||||
Результат: @JOB_RESULT@.
|
||||
|
||||
# Subject: Process @EXECUTABLE@ could not be executed
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
|
||||
@ -158,7 +158,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Јединица @UNIT@ је завршила са покретањем.
|
||||
|
||||
Исход покретања је @RESULT@.
|
||||
Исход покретања је @JOB_RESULT@.
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: Јединица @UNIT@ је почела са гашењем
|
||||
@ -181,7 +181,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Јединица @UNIT@ је пукла.
|
||||
|
||||
Исход је @RESULT@.
|
||||
Исход је @JOB_RESULT@.
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: Јединица @UNIT@ је почела са поновним учитавањем свог подешавања
|
||||
@ -197,7 +197,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
Јединица @UNIT@ је завршила са поновним учитавањем свог подешавања
|
||||
|
||||
Исход је @RESULT@.
|
||||
Исход је @JOB_RESULT@.
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: Процес @EXECUTABLE@ није могао бити извршен
|
||||
|
||||
@ -156,7 +156,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
@UNIT@ 单元已结束启动。
|
||||
|
||||
启动结果为“@RESULT@”。
|
||||
启动结果为“@JOB_RESULT@”。
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: @UNIT@ 单元已开始停止操作
|
||||
@ -179,7 +179,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
@UNIT@ 单元已失败。
|
||||
|
||||
结果为“@RESULT@”。
|
||||
结果为“@JOB_RESULT@”。
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: @UNIT@ 单元已开始重新载入其配置
|
||||
@ -195,7 +195,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
@UNIT@ 单元已结束配置重载入操作。
|
||||
|
||||
结果为“@RESULT@”。
|
||||
结果为“@JOB_RESULT@”。
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: 进程 @EXECUTABLE@ 无法执行
|
||||
|
||||
@ -160,7 +160,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
單位 @UNIT@ 啟動已結束。
|
||||
|
||||
啟動結果為 @RESULT@。
|
||||
啟動結果為 @JOB_RESULT@。
|
||||
|
||||
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
||||
Subject: 單位 @UNIT@ 已開始關閉
|
||||
@ -183,7 +183,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
單位 @UNIT@ 已失敗。
|
||||
|
||||
結果為 @RESULT@。
|
||||
結果為 @JOB_RESULT@。
|
||||
|
||||
-- d34d037fff1847e6ae669a370e694725
|
||||
Subject: 單位 @UNIT@ 已開始重新載入其設定
|
||||
@ -199,7 +199,7 @@ Support: %SUPPORT_URL%
|
||||
|
||||
單位 @UNIT@ 已結束重新載入其設定
|
||||
|
||||
結果為 @RESULT@。
|
||||
結果為 @JOB_RESULT@。
|
||||
|
||||
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
||||
Subject: 行程 @EXECUTABLE@ 無法執行
|
||||
|
||||
28
coccinelle/cmp.cocci
Normal file
28
coccinelle/cmp.cocci
Normal file
@ -0,0 +1,28 @@
|
||||
@@
|
||||
expression x, y;
|
||||
@@
|
||||
- if (x < y)
|
||||
- return -1;
|
||||
- if (x > y)
|
||||
- return 1;
|
||||
- return 0;
|
||||
+ return CMP(x, y);
|
||||
@@
|
||||
expression x, y;
|
||||
@@
|
||||
- if (x < y)
|
||||
- return -1;
|
||||
- else if (x > y)
|
||||
- return 1;
|
||||
- return 0;
|
||||
+ return CMP(x, y);
|
||||
@@
|
||||
expression x, y;
|
||||
@@
|
||||
- if (x < y)
|
||||
- return -1;
|
||||
- else if (x > y)
|
||||
- return 1;
|
||||
- else
|
||||
- return 0;
|
||||
+ return CMP(x, y);
|
||||
29
coccinelle/iovec-make.cocci
Normal file
29
coccinelle/iovec-make.cocci
Normal file
@ -0,0 +1,29 @@
|
||||
@@
|
||||
expression x, y, p, l;
|
||||
@@
|
||||
- x[y].iov_base = p;
|
||||
- x[y].iov_len = l;
|
||||
- y++;
|
||||
+ x[y++] = IOVEC_MAKE(p, l);
|
||||
@@
|
||||
expression x, p, l;
|
||||
@@
|
||||
- x.iov_base = p;
|
||||
- x.iov_len = l;
|
||||
+ x = IOVEC_MAKE(p, l);
|
||||
@@
|
||||
expression x, p, l;
|
||||
@@
|
||||
- x->iov_base = p;
|
||||
- x->iov_len = l;
|
||||
+ *x = IOVEC_MAKE(p, l);
|
||||
@@
|
||||
expression s;
|
||||
@@
|
||||
- IOVEC_MAKE(s, strlen(s));
|
||||
+ IOVEC_MAKE_STRING(s);
|
||||
@@
|
||||
expression x, y, z;
|
||||
@@
|
||||
- x = (struct iovec) { .iov_base = y, .iov_len = z };
|
||||
+ x = IOVEC_MAKE(y, z);
|
||||
54
coccinelle/redundant-if.cocci
Normal file
54
coccinelle/redundant-if.cocci
Normal file
@ -0,0 +1,54 @@
|
||||
@@
|
||||
expression r;
|
||||
@@
|
||||
- if (r < 0)
|
||||
- return r;
|
||||
- if (r == 0)
|
||||
- return 0;
|
||||
+ if (r <= 0)
|
||||
+ return r;
|
||||
@@
|
||||
expression r;
|
||||
@@
|
||||
- if (r == 0)
|
||||
- return 0;
|
||||
- if (r < 0)
|
||||
- return r;
|
||||
+ if (r <= 0)
|
||||
+ return r;
|
||||
@@
|
||||
expression r;
|
||||
@@
|
||||
- if (r < 0)
|
||||
- return r;
|
||||
- if (r == 0)
|
||||
- return r;
|
||||
+ if (r <= 0)
|
||||
+ return r;
|
||||
@@
|
||||
expression r;
|
||||
@@
|
||||
- if (r == 0)
|
||||
- return r;
|
||||
- if (r < 0)
|
||||
- return r;
|
||||
+ if (r <= 0)
|
||||
+ return r;
|
||||
@@
|
||||
expression r;
|
||||
@@
|
||||
- if (r < 0)
|
||||
- return r;
|
||||
- if (r > 0)
|
||||
- return r;
|
||||
+ if (r != 0)
|
||||
+ return r;
|
||||
@@
|
||||
expression r;
|
||||
@@
|
||||
- if (r > 0)
|
||||
- return r;
|
||||
- if (r < 0)
|
||||
- return r;
|
||||
+ if (r != 0)
|
||||
+ return r;
|
||||
7
coccinelle/swap-two.cocci
Normal file
7
coccinelle/swap-two.cocci
Normal file
@ -0,0 +1,7 @@
|
||||
@@
|
||||
expression x, y, z;
|
||||
@@
|
||||
- z = x;
|
||||
- x = y;
|
||||
- y = z;
|
||||
+ SWAP_TWO(x, y);
|
||||
42
coccinelle/synthetic-errno.cocci
Normal file
42
coccinelle/synthetic-errno.cocci
Normal file
@ -0,0 +1,42 @@
|
||||
@@
|
||||
expression e;
|
||||
expression list args;
|
||||
@@
|
||||
- log_debug(args);
|
||||
- return -e;
|
||||
+ return log_debug_errno(SYNTHETIC_ERRNO(e), args);
|
||||
@@
|
||||
expression e;
|
||||
expression list args;
|
||||
@@
|
||||
- log_info(args);
|
||||
- return -e;
|
||||
+ return log_info_errno(SYNTHETIC_ERRNO(e), args);
|
||||
@@
|
||||
expression e;
|
||||
expression list args;
|
||||
@@
|
||||
- log_notice(args);
|
||||
- return -e;
|
||||
+ return log_notice_errno(SYNTHETIC_ERRNO(e), args);
|
||||
@@
|
||||
expression e;
|
||||
expression list args;
|
||||
@@
|
||||
- log_error(args);
|
||||
- return -e;
|
||||
+ return log_error_errno(SYNTHETIC_ERRNO(e), args);
|
||||
@@
|
||||
expression e;
|
||||
expression list args;
|
||||
@@
|
||||
- log_emergency(args);
|
||||
- return -e;
|
||||
+ return log_emergency_errno(SYNTHETIC_ERRNO(e), args);
|
||||
@@
|
||||
identifier log_LEVEL_errno =~ "^log_(debug|info|notice|warning|error|emergency)_errno$";
|
||||
identifier ERRNO =~ "^E[A-Z]+$";
|
||||
expression list args;
|
||||
@@
|
||||
- return log_LEVEL_errno(ERRNO, args);
|
||||
+ return log_LEVEL_errno(SYNTHETIC_ERRNO(ERRNO), args);
|
||||
460
doc/CODING_STYLE
460
doc/CODING_STYLE
@ -1,460 +0,0 @@
|
||||
- 8ch indent, no tabs, except for files in man/ which are 2ch indent,
|
||||
and still no tabs
|
||||
|
||||
- We prefer /* comments */ over // comments in code you commit, please. This
|
||||
way // comments are left for developers to use for local, temporary
|
||||
commenting of code for debug purposes (i.e. uncommittable stuff), making such
|
||||
comments easily discernable from explanatory, documenting code comments
|
||||
(i.e. committable stuff).
|
||||
|
||||
- Don't break code lines too eagerly. We do *not* force line breaks at 80ch,
|
||||
all of today's screens should be much larger than that. But then again, don't
|
||||
overdo it, ~119ch should be enough really. The .editorconfig, .vimrc and
|
||||
.dir-locals.el files contained in the repository will set this limit up for
|
||||
you automatically, if you let them (as well as a few other things).
|
||||
|
||||
- Variables and functions *must* be static, unless they have a
|
||||
prototype, and are supposed to be exported.
|
||||
|
||||
- structs in MixedCase (with exceptions, such as public API structs),
|
||||
variables + functions in lower_case.
|
||||
|
||||
- The destructors always unregister the object from the next bigger
|
||||
object, not the other way around
|
||||
|
||||
- To minimize strict aliasing violations, we prefer unions over casting
|
||||
|
||||
- For robustness reasons, destructors should be able to destruct
|
||||
half-initialized objects, too
|
||||
|
||||
- Error codes are returned as negative Exxx. e.g. return -EINVAL. There
|
||||
are some exceptions: for constructors, it is OK to return NULL on
|
||||
OOM. For lookup functions, NULL is fine too for "not found".
|
||||
|
||||
Be strict with this. When you write a function that can fail due to
|
||||
more than one cause, it *really* should have "int" as return value
|
||||
for the error code.
|
||||
|
||||
- Do not bother with error checking whether writing to stdout/stderr
|
||||
worked.
|
||||
|
||||
- Do not log errors from "library" code, only do so from "main
|
||||
program" code. (With one exception: it is OK to log with DEBUG level
|
||||
from any code, with the exception of maybe inner loops).
|
||||
|
||||
- Always check OOM. There is no excuse. In program code, you can use
|
||||
"log_oom()" for then printing a short message, but not in "library" code.
|
||||
|
||||
- Do not issue NSS requests (that includes user name and host name
|
||||
lookups) from PID 1 as this might trigger deadlocks when those
|
||||
lookups involve synchronously talking to services that we would need
|
||||
to start up
|
||||
|
||||
- Do not synchronously talk to any other service from PID 1, due to
|
||||
risk of deadlocks
|
||||
|
||||
- Avoid fixed-size string buffers, unless you really know the maximum
|
||||
size and that maximum size is small. They are a source of errors,
|
||||
since they possibly result in truncated strings. It is often nicer
|
||||
to use dynamic memory, alloca() or VLAs. If you do allocate fixed-size
|
||||
strings on the stack, then it is probably only OK if you either
|
||||
use a maximum size such as LINE_MAX, or count in detail the maximum
|
||||
size a string can have. (DECIMAL_STR_MAX and DECIMAL_STR_WIDTH
|
||||
macros are your friends for this!)
|
||||
|
||||
Or in other words, if you use "char buf[256]" then you are likely
|
||||
doing something wrong!
|
||||
|
||||
- Stay uniform. For example, always use "usec_t" for time
|
||||
values. Do not mix usec and msec, and usec and whatnot.
|
||||
|
||||
- Make use of _cleanup_free_ and friends. It makes your code much
|
||||
nicer to read (and shorter)!
|
||||
|
||||
- Be exceptionally careful when formatting and parsing floating point
|
||||
numbers. Their syntax is locale dependent (i.e. "5.000" in en_US is
|
||||
generally understood as 5, while on de_DE as 5000.).
|
||||
|
||||
- Try to use this:
|
||||
|
||||
void foo() {
|
||||
}
|
||||
|
||||
instead of this:
|
||||
|
||||
void foo()
|
||||
{
|
||||
}
|
||||
|
||||
But it is OK if you do not.
|
||||
|
||||
- Single-line "if" blocks should not be enclosed in {}. Use this:
|
||||
|
||||
if (foobar)
|
||||
waldo();
|
||||
|
||||
instead of this:
|
||||
|
||||
if (foobar) {
|
||||
waldo();
|
||||
}
|
||||
|
||||
- Do not write "foo ()", write "foo()".
|
||||
|
||||
- Please use streq() and strneq() instead of strcmp(), strncmp() where
|
||||
applicable (i.e. wherever you just care about equality/inequality, not about
|
||||
the sorting order).
|
||||
|
||||
- Preferably allocate stack variables on the top of the block:
|
||||
|
||||
{
|
||||
int a, b;
|
||||
|
||||
a = 5;
|
||||
b = a;
|
||||
}
|
||||
|
||||
- Unless you allocate an array, "double" is always the better choice
|
||||
than "float". Processors speak "double" natively anyway, so this is
|
||||
no speed benefit, and on calls like printf() "float"s get promoted
|
||||
to "double"s anyway, so there is no point.
|
||||
|
||||
- Do not mix function invocations with variable definitions in one
|
||||
line. Wrong:
|
||||
|
||||
{
|
||||
int a = foobar();
|
||||
uint64_t x = 7;
|
||||
}
|
||||
|
||||
Right:
|
||||
|
||||
{
|
||||
int a;
|
||||
uint64_t x = 7;
|
||||
|
||||
a = foobar();
|
||||
}
|
||||
|
||||
- Use "goto" for cleaning up, and only use it for that. i.e. you may
|
||||
only jump to the end of a function, and little else. Never jump
|
||||
backwards!
|
||||
|
||||
- Think about the types you use. If a value cannot sensibly be
|
||||
negative, do not use "int", but use "unsigned".
|
||||
|
||||
- Use "char" only for actual characters. Use "uint8_t" or "int8_t"
|
||||
when you actually mean a byte-sized signed or unsigned
|
||||
integers. When referring to a generic byte, we generally prefer the
|
||||
unsigned variant "uint8_t". Do not use types based on "short". They
|
||||
*never* make sense. Use ints, longs, long longs, all in
|
||||
unsigned+signed fashion, and the fixed size types
|
||||
uint8_t/uint16_t/uint32_t/uint64_t/int8_t/int16_t/int32_t and so on,
|
||||
as well as size_t, but nothing else. Do not use kernel types like
|
||||
u32 and so on, leave that to the kernel.
|
||||
|
||||
- Public API calls (i.e. functions exported by our shared libraries)
|
||||
must be marked "_public_" and need to be prefixed with "sd_". No
|
||||
other functions should be prefixed like that.
|
||||
|
||||
- In public API calls, you *must* validate all your input arguments for
|
||||
programming error with assert_return() and return a sensible return
|
||||
code. In all other calls, it is recommended to check for programming
|
||||
errors with a more brutal assert(). We are more forgiving to public
|
||||
users than for ourselves! Note that assert() and assert_return()
|
||||
really only should be used for detecting programming errors, not for
|
||||
runtime errors. assert() and assert_return() by usage of _likely_()
|
||||
inform the compiler that he should not expect these checks to fail,
|
||||
and they inform fellow programmers about the expected validity and
|
||||
range of parameters.
|
||||
|
||||
- Never use strtol(), atoi() and similar calls. Use safe_atoli(),
|
||||
safe_atou32() and suchlike instead. They are much nicer to use in
|
||||
most cases and correctly check for parsing errors.
|
||||
|
||||
- For every function you add, think about whether it is a "logging"
|
||||
function or a "non-logging" function. "Logging" functions do logging
|
||||
on their own, "non-logging" function never log on their own and
|
||||
expect their callers to log. All functions in "library" code,
|
||||
i.e. in src/shared/ and suchlike must be "non-logging". Every time a
|
||||
"logging" function calls a "non-logging" function, it should log
|
||||
about the resulting errors. If a "logging" function calls another
|
||||
"logging" function, then it should not generate log messages, so
|
||||
that log messages are not generated twice for the same errors.
|
||||
|
||||
- Avoid static variables, except for caches and very few other
|
||||
cases. Think about thread-safety! While most of our code is never
|
||||
used in threaded environments, at least the library code should make
|
||||
sure it works correctly in them. Instead of doing a lot of locking
|
||||
for that, we tend to prefer using TLS to do per-thread caching (which
|
||||
only works for small, fixed-size cache objects), or we disable
|
||||
caching for any thread that is not the main thread. Use
|
||||
is_main_thread() to detect whether the calling thread is the main
|
||||
thread.
|
||||
|
||||
- Command line option parsing:
|
||||
- Do not print full help() on error, be specific about the error.
|
||||
- Do not print messages to stdout on error.
|
||||
- Do not POSIX_ME_HARDER unless necessary, i.e. avoid "+" in option string.
|
||||
|
||||
- Do not write functions that clobber call-by-reference variables on
|
||||
failure. Use temporary variables for these cases and change the
|
||||
passed in variables only on success.
|
||||
|
||||
- When you allocate a file descriptor, it should be made O_CLOEXEC
|
||||
right from the beginning, as none of our files should leak to forked
|
||||
binaries by default. Hence, whenever you open a file, O_CLOEXEC must
|
||||
be specified, right from the beginning. This also applies to
|
||||
sockets. Effectively this means that all invocations to:
|
||||
|
||||
a) open() must get O_CLOEXEC passed
|
||||
b) socket() and socketpair() must get SOCK_CLOEXEC passed
|
||||
c) recvmsg() must get MSG_CMSG_CLOEXEC set
|
||||
d) F_DUPFD_CLOEXEC should be used instead of F_DUPFD, and so on
|
||||
f) invocations of fopen() should take "e"
|
||||
|
||||
- We never use the POSIX version of basename() (which glibc defines it in
|
||||
libgen.h), only the GNU version (which glibc defines in string.h).
|
||||
The only reason to include libgen.h is because dirname()
|
||||
is needed. Every time you need that please immediately undefine
|
||||
basename(), and add a comment about it, so that no code ever ends up
|
||||
using the POSIX version!
|
||||
|
||||
- Use the bool type for booleans, not integers. One exception: in public
|
||||
headers (i.e those in src/systemd/sd-*.h) use integers after all, as "bool"
|
||||
is C99 and in our public APIs we try to stick to C89 (with a few extension).
|
||||
|
||||
- When you invoke certain calls like unlink(), or mkdir_p() and you
|
||||
know it is safe to ignore the error it might return (because a later
|
||||
call would detect the failure anyway, or because the error is in an
|
||||
error path and you thus couldn't do anything about it anyway), then
|
||||
make this clear by casting the invocation explicitly to (void). Code
|
||||
checks like Coverity understand that, and will not complain about
|
||||
ignored error codes. Hence, please use this:
|
||||
|
||||
(void) unlink("/foo/bar/baz");
|
||||
|
||||
instead of just this:
|
||||
|
||||
unlink("/foo/bar/baz");
|
||||
|
||||
Don't cast function calls to (void) that return no error
|
||||
conditions. Specifically, the various xyz_unref() calls that return a NULL
|
||||
object shouldn't be cast to (void), since not using the return value does not
|
||||
hide any errors.
|
||||
|
||||
- Don't invoke exit(), ever. It is not replacement for proper error
|
||||
handling. Please escalate errors up your call chain, and use normal
|
||||
"return" to exit from the main function of a process. If you
|
||||
fork()ed off a child process, please use _exit() instead of exit(),
|
||||
so that the exit handlers are not run.
|
||||
|
||||
- Please never use dup(). Use fcntl(fd, F_DUPFD_CLOEXEC, 3)
|
||||
instead. For two reason: first, you want O_CLOEXEC set on the new fd
|
||||
(see above). Second, dup() will happily duplicate your fd as 0, 1,
|
||||
2, i.e. stdin, stdout, stderr, should those fds be closed. Given the
|
||||
special semantics of those fds, it's probably a good idea to avoid
|
||||
them. F_DUPFD_CLOEXEC with "3" as parameter avoids them.
|
||||
|
||||
- When you define a destructor or unref() call for an object, please
|
||||
accept a NULL object and simply treat this as NOP. This is similar
|
||||
to how libc free() works, which accepts NULL pointers and becomes a
|
||||
NOP for them. By following this scheme a lot of if checks can be
|
||||
removed before invoking your destructor, which makes the code
|
||||
substantially more readable and robust.
|
||||
|
||||
- Related to this: when you define a destructor or unref() call for an
|
||||
object, please make it return the same type it takes and always
|
||||
return NULL from it. This allows writing code like this:
|
||||
|
||||
p = foobar_unref(p);
|
||||
|
||||
which will always work regardless if p is initialized or not, and
|
||||
guarantees that p is NULL afterwards, all in just one line.
|
||||
|
||||
- Use alloca(), but never forget that it is not OK to invoke alloca()
|
||||
within a loop or within function call parameters. alloca() memory is
|
||||
released at the end of a function, and not at the end of a {}
|
||||
block. Thus, if you invoke it in a loop, you keep increasing the
|
||||
stack pointer without ever releasing memory again. (VLAs have better
|
||||
behaviour in this case, so consider using them as an alternative.)
|
||||
Regarding not using alloca() within function parameters, see the
|
||||
BUGS section of the alloca(3) man page.
|
||||
|
||||
- Use memzero() or even better zero() instead of memset(..., 0, ...)
|
||||
|
||||
- Instead of using memzero()/memset() to initialize structs allocated
|
||||
on the stack, please try to use c99 structure initializers. It's
|
||||
short, prettier and actually even faster at execution. Hence:
|
||||
|
||||
struct foobar t = {
|
||||
.foo = 7,
|
||||
.bar = "bazz",
|
||||
};
|
||||
|
||||
instead of:
|
||||
|
||||
struct foobar t;
|
||||
zero(t);
|
||||
t.foo = 7;
|
||||
t.bar = "bazz";
|
||||
|
||||
- When returning a return code from main(), please preferably use
|
||||
EXIT_FAILURE and EXIT_SUCCESS as defined by libc.
|
||||
|
||||
- The order in which header files are included doesn't matter too
|
||||
much. systemd-internal headers must not rely on an include order, so
|
||||
it is safe to include them in any order possible.
|
||||
However, to not clutter global includes, and to make sure internal
|
||||
definitions will not affect global headers, please always include the
|
||||
headers of external components first (these are all headers enclosed
|
||||
in <>), followed by our own exported headers (usually everything
|
||||
that's prefixed by "sd-"), and then followed by internal headers.
|
||||
Furthermore, in all three groups, order all includes alphabetically
|
||||
so duplicate includes can easily be detected.
|
||||
|
||||
- To implement an endless loop, use "for (;;)" rather than "while
|
||||
(1)". The latter is a bit ugly anyway, since you probably really
|
||||
meant "while (true)"... To avoid the discussion what the right
|
||||
always-true expression for an infinite while() loop is our
|
||||
recommendation is to simply write it without any such expression by
|
||||
using "for (;;)".
|
||||
|
||||
- Never use the "off_t" type, and particularly avoid it in public
|
||||
APIs. It's really weirdly defined, as it usually is 64bit and we
|
||||
don't support it any other way, but it could in theory also be
|
||||
32bit. Which one it is depends on a compiler switch chosen by the
|
||||
compiled program, which hence corrupts APIs using it unless they can
|
||||
also follow the program's choice. Moreover, in systemd we should
|
||||
parse values the same way on all architectures and cannot expose
|
||||
off_t values over D-Bus. To avoid any confusion regarding conversion
|
||||
and ABIs, always use simply uint64_t directly.
|
||||
|
||||
- Commit message subject lines should be prefixed with an appropriate
|
||||
component name of some kind. For example "journal: ", "nspawn: " and
|
||||
so on.
|
||||
|
||||
- Do not use "Signed-Off-By:" in your commit messages. That's a kernel
|
||||
thing we don't do in the systemd project.
|
||||
|
||||
- Avoid leaving long-running child processes around, i.e. fork()s that
|
||||
are not followed quickly by an execv() in the child. Resource
|
||||
management is unclear in this case, and memory CoW will result in
|
||||
unexpected penalties in the parent much, much later on.
|
||||
|
||||
- Don't block execution for arbitrary amounts of time using usleep()
|
||||
or a similar call, unless you really know what you do. Just "giving
|
||||
something some time", or so is a lazy excuse. Always wait for the
|
||||
proper event, instead of doing time-based poll loops.
|
||||
|
||||
- To determine the length of a constant string "foo", don't bother
|
||||
with sizeof("foo")-1, please use STRLEN() instead.
|
||||
|
||||
- If you want to concatenate two or more strings, consider using
|
||||
strjoin() rather than asprintf(), as the latter is a lot
|
||||
slower. This matters particularly in inner loops.
|
||||
|
||||
- Please avoid using global variables as much as you can. And if you
|
||||
do use them make sure they are static at least, instead of
|
||||
exported. Especially in library-like code it is important to avoid
|
||||
global variables. Why are global variables bad? They usually hinder
|
||||
generic reusability of code (since they break in threaded programs,
|
||||
and usually would require locking there), and as the code using them
|
||||
has side-effects make programs non-transparent. That said, there are
|
||||
many cases where they explicitly make a lot of sense, and are OK to
|
||||
use. For example, the log level and target in log.c is stored in a
|
||||
global variable, and that's OK and probably expected by most. Also
|
||||
in many cases we cache data in global variables. If you add more
|
||||
caches like this, please be careful however, and think about
|
||||
threading. Only use static variables if you are sure that
|
||||
thread-safety doesn't matter in your case. Alternatively consider
|
||||
using TLS, which is pretty easy to use with gcc's "thread_local"
|
||||
concept. It's also OK to store data that is inherently global in
|
||||
global variables, for example data parsed from command lines, see
|
||||
below.
|
||||
|
||||
- If you parse a command line, and want to store the parsed parameters
|
||||
in global variables, please consider prefixing their names with
|
||||
"arg_". We have been following this naming rule in most of our
|
||||
tools, and we should continue to do so, as it makes it easy to
|
||||
identify command line parameter variables, and makes it clear why it
|
||||
is OK that they are global variables.
|
||||
|
||||
- When exposing public C APIs, be careful what function parameters you make
|
||||
"const". For example, a parameter taking a context object should probably not
|
||||
be "const", even if you are writing an otherwise read-only accessor function
|
||||
for it. The reason is that making it "const" fixates the contract that your
|
||||
call won't alter the object ever, as part of the API. However, that's often
|
||||
quite a promise, given that this even prohibits object-internal caching or
|
||||
lazy initialization of object variables. Moreover it's usually not too useful
|
||||
for client applications. Hence: please be careful and avoid "const" on object
|
||||
parameters, unless you are very sure "const" is appropriate.
|
||||
|
||||
- Make sure to enforce limits on every user controllable resource. If the user
|
||||
can allocate resources in your code, your code must enforce some form of
|
||||
limits after which it will refuse operation. It's fine if it is hard-coded (at
|
||||
least initially), but it needs to be there. This is particularly important
|
||||
for objects that unprivileged users may allocate, but also matters for
|
||||
everything else any user may allocated.
|
||||
|
||||
- htonl()/ntohl() and htons()/ntohs() are weird. Please use htobe32() and
|
||||
htobe16() instead, it's much more descriptive, and actually says what really
|
||||
is happening, after all htonl() and htons() don't operate on longs and
|
||||
shorts as their name would suggest, but on uint32_t and uint16_t. Also,
|
||||
"network byte order" is just a weird name for "big endian", hence we might
|
||||
want to call it "big endian" right-away.
|
||||
|
||||
- You might wonder what kind of common code belongs in src/shared/ and what
|
||||
belongs in src/basic/. The split is like this: anything that uses public APIs
|
||||
we expose (i.e. any of the sd-bus, sd-login, sd-id128, ... APIs) must be
|
||||
located in src/shared/. All stuff that only uses external libraries from
|
||||
other projects (such as glibc's APIs), or APIs from src/basic/ itself should
|
||||
be placed in src/basic/. Conversely, src/libsystemd/ may only use symbols
|
||||
from src/basic, but not from src/shared/. To summarize:
|
||||
|
||||
src/basic/ → may be used by all code in the tree
|
||||
→ may not use any code outside of src/basic/
|
||||
|
||||
src/libsystemd/ → may be used by all code in the tree, except for code in src/basic/
|
||||
→ may not use any code outside of src/basic/, src/libsystemd/
|
||||
|
||||
src/shared/ → may be used by all code in the tree, except for code in src/basic/, src/libsystemd/
|
||||
→ may not use any code outside of src/basic/, src/libsystemd/, src/shared/
|
||||
|
||||
- Our focus is on the GNU libc (glibc), not any other libcs. If other libcs are
|
||||
incompatible with glibc it's on them. However, if there are equivalent POSIX
|
||||
and Linux/GNU-specific APIs, we generally prefer the POSIX APIs. If there
|
||||
aren't, we are happy to use GNU or Linux APIs, and expect non-GNU
|
||||
implementations of libc to catch up with glibc.
|
||||
|
||||
- Whenever installing a signal handler, make sure to set SA_RESTART for it, so
|
||||
that interrupted system calls are automatically restarted, and we minimize
|
||||
hassles with handling EINTR (in particular as EINTR handling is pretty broken
|
||||
on Linux).
|
||||
|
||||
- When applying C-style unescaping as well as specifier expansion on the same
|
||||
string, always apply the C-style unescaping fist, followed by the specifier
|
||||
expansion. When doing the reverse, make sure to escape '%' in specifier-style
|
||||
first (i.e. '%' → '%%'), and then do C-style escaping where necessary.
|
||||
|
||||
- It's a good idea to use O_NONBLOCK when opening 'foreign' regular files, i.e
|
||||
file system objects that are supposed to be regular files whose paths where
|
||||
specified by the user and hence might actually refer to other types of file
|
||||
system objects. This is a good idea so that we don't end up blocking on
|
||||
'strange' file nodes, for example if the user pointed us to a FIFO or device
|
||||
node which may block when opening. Moreover even for actual regular files
|
||||
O_NONBLOCK has a benefit: it bypasses any mandatory lock that might be in
|
||||
effect on the regular file. If in doubt consider turning off O_NONBLOCK again
|
||||
after opening.
|
||||
|
||||
- When referring to a configuration file option in the documentation and such,
|
||||
please always suffix it with "=", to indicate that it is a configuration file
|
||||
setting.
|
||||
|
||||
- When referring to a command line option in the documentation and such, please
|
||||
always prefix with "--" or "-" (as appropriate), to indicate that it is a
|
||||
command line option.
|
||||
|
||||
- When referring to a file system path that is a directory, please always
|
||||
suffix it with "/", to indicate that it is a directory, not a regular file
|
||||
(or other file system object).
|
||||
@ -1,71 +0,0 @@
|
||||
Porting systemd To New Distributions
|
||||
|
||||
HOWTO:
|
||||
You need to make the follow changes to adapt systemd to your
|
||||
distribution:
|
||||
|
||||
1) Find the right configure parameters for:
|
||||
|
||||
-D rootprefix=
|
||||
-D sysvinit-path=
|
||||
-D sysvrcnd-path=
|
||||
-D rc-local=
|
||||
-D halt-local=
|
||||
-D loadkeys-path=
|
||||
-D setfont-path=
|
||||
-D tty-gid=
|
||||
-D ntp-servers=
|
||||
-D dns-servers=
|
||||
-D support-url=
|
||||
|
||||
2) Try it out. Play around (as an ordinary user) with
|
||||
'/usr/lib/systemd/systemd --test --system' for a test run
|
||||
of systemd without booting. This will read the unit files and
|
||||
print the initial transaction it would execute during boot-up.
|
||||
This will also inform you about ordering loops and suchlike.
|
||||
|
||||
NTP POOL:
|
||||
By default, systemd-timesyncd uses the Google Public NTP servers
|
||||
time[1-4].google.com, if no other NTP configuration is available. They
|
||||
serve time that uses a leap second smear, and can be up to .5s off from
|
||||
servers that use stepped leap seconds.
|
||||
|
||||
https://developers.google.com/time/smear
|
||||
|
||||
If you prefer to use leap second steps, please register your own
|
||||
vendor pool at ntp.org and make it the built-in default by
|
||||
passing --with-ntp-servers= to configure. Registering vendor
|
||||
pools is free:
|
||||
|
||||
http://www.pool.ntp.org/en/vendors.html
|
||||
|
||||
Use -D ntp-servers= to direct systemd-timesyncd to different fallback
|
||||
NTP servers.
|
||||
|
||||
DNS SERVERS:
|
||||
By default, systemd-resolved uses the Google Public DNS servers
|
||||
8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844 as
|
||||
fallback, if no other DNS configuration is available.
|
||||
|
||||
Use -D dns-servers= to direct systemd-resolved to different fallback
|
||||
DNS servers.
|
||||
|
||||
PAM:
|
||||
The default PAM config shipped by systemd is really bare bones.
|
||||
It does not include many modules your distro might want to enable
|
||||
to provide a more seamless experience. For example, limits set in
|
||||
/etc/security/limits.conf will not be read unless you load pam_limits.
|
||||
Make sure you add modules your distro expects from user services.
|
||||
|
||||
Pass -D pamconfdir=no to meson to avoid installing this file and
|
||||
instead install your own.
|
||||
|
||||
CONTRIBUTING UPSTREAM:
|
||||
We generally do no longer accept distribution-specific patches to
|
||||
systemd upstream. If you have to make changes to systemd's source code
|
||||
to make it work on your distribution, unless your code is generic
|
||||
enough to be generally useful, we are unlikely to merge it. Please
|
||||
always consider adopting the upstream defaults. If that is not
|
||||
possible, please maintain the relevant patches downstream.
|
||||
|
||||
Thank you for understanding.
|
||||
122
doc/HACKING
122
doc/HACKING
@ -1,122 +0,0 @@
|
||||
HACKING ON SYSTEMD
|
||||
|
||||
We welcome all contributions to systemd. If you notice a bug or a missing
|
||||
feature, please feel invited to fix it, and submit your work as a github Pull
|
||||
Request (PR):
|
||||
|
||||
https://github.com/systemd/systemd/pull/new
|
||||
|
||||
Please make sure to follow our Coding Style when submitting patches. See
|
||||
doc/CODING_STYLE for details. Also have a look at our Contribution Guidelines:
|
||||
|
||||
https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md
|
||||
|
||||
When adding new functionality, tests should be added. For shared functionality
|
||||
(in src/basic and src/shared) unit tests should be sufficient. The general
|
||||
policy is to keep tests in matching files underneath src/test,
|
||||
e.g. src/test/test-path-util.c contains tests for any functions in
|
||||
src/basic/path-util.c. If adding a new source file, consider adding a matching
|
||||
test executable. For features at a higher level, tests in src/test/ are very
|
||||
strongly recommended. If that is no possible, integration tests in test/ are
|
||||
encouraged.
|
||||
|
||||
Please also have a look at our list of code quality tools we have setup for systemd,
|
||||
to ensure our codebase stays in good shape:
|
||||
|
||||
https://github.com/systemd/systemd/blob/master/doc/CODE_QUALITY.md
|
||||
|
||||
Please always test your work before submitting a PR. For many of the components
|
||||
of systemd testing is straight-forward as you can simply compile systemd and
|
||||
run the relevant tool from the build directory.
|
||||
|
||||
For some components (most importantly, systemd/PID1 itself) this is not
|
||||
possible, however. In order to simplify testing for cases like this we provide
|
||||
a set of "mkosi" build files directly in the source tree. "mkosi" is a tool for
|
||||
building clean OS images from an upstream distribution in combination with a
|
||||
fresh build of the project in the local working directory. To make use of this,
|
||||
please acquire "mkosi" from https://github.com/systemd/mkosi first, unless your
|
||||
distribution has packaged it already and you can get it from there. After the
|
||||
tool is installed it is sufficient to type "mkosi" in the systemd project
|
||||
directory to generate a disk image "image.raw" you can boot either in
|
||||
systemd-nspawn or in an UEFI-capable VM:
|
||||
|
||||
# systemd-nspawn -bi image.raw
|
||||
|
||||
or:
|
||||
|
||||
# qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd -hda image.raw
|
||||
|
||||
Every time you rerun the "mkosi" command a fresh image is built, incorporating
|
||||
all current changes you made to the project tree.
|
||||
|
||||
Alternatively, you may install the systemd version from your git check-out
|
||||
directly on top of your host system's directory tree. This mostly works fine,
|
||||
but of course you should know what you are doing as you might make your system
|
||||
unbootable in case of a bug in your changes. Also, you might step into your
|
||||
package manager's territory with this. Be careful!
|
||||
|
||||
And never forget: most distributions provide very simple and convenient ways to
|
||||
install all development packages necessary to build systemd. For example, on
|
||||
Fedora the following command line should be sufficient to install all of
|
||||
systemd's build dependencies:
|
||||
|
||||
# dnf builddep systemd
|
||||
|
||||
Putting this all together, here's a series of commands for preparing a patch
|
||||
for systemd (this example is for Fedora):
|
||||
|
||||
$ sudo dnf builddep systemd # install build dependencies
|
||||
$ sudo dnf install mkosi # install tool to quickly build images
|
||||
$ git clone https://github.com/systemd/systemd.git
|
||||
$ cd systemd
|
||||
$ vim src/core/main.c # or wherever you'd like to make your changes
|
||||
$ meson build # configure the build
|
||||
$ ninja -C build # build it locally, see if everything compiles fine
|
||||
$ ninja -C build test # run some simple regression tests
|
||||
$ (umask 077; echo 123 > mkosi.rootpw) # set root password used by mkosi
|
||||
$ sudo mkosi # build a test image
|
||||
$ sudo systemd-nspawn -bi image.raw # boot up the test image
|
||||
$ git add -p # interactively put together your patch
|
||||
$ git commit # commit it
|
||||
$ git push REMOTE HEAD:refs/heads/BRANCH
|
||||
# where REMOTE is your "fork" on github
|
||||
# and BRANCH is a branch name.
|
||||
|
||||
And after that, head over to your repo on github and click "Compare & pull request"
|
||||
|
||||
Happy hacking!
|
||||
|
||||
|
||||
FUZZERS
|
||||
|
||||
systemd includes fuzzers in src/fuzz that use libFuzzer and are automatically
|
||||
run by OSS-Fuzz (https://github.com/google/oss-fuzz) with sanitizers. To add a
|
||||
fuzz target, create a new src/fuzz/fuzz-foo.c file with a LLVMFuzzerTestOneInput
|
||||
function and add it to the list in src/fuzz/meson.build.
|
||||
|
||||
Whenever possible, a seed corpus and a dictionary should also be added with new
|
||||
fuzz targets. The dictionary should be named src/fuzz/fuzz-foo.dict and the seed
|
||||
corpus should be built and exported as $OUT/fuzz-foo_seed_corpus.zip in
|
||||
tools/oss-fuzz.sh.
|
||||
|
||||
The fuzzers can be built locally if you have libFuzzer installed by running
|
||||
tools/oss-fuzz.sh. You should also confirm that the fuzzer runs in the
|
||||
OSS-Fuzz environment by checking out the OSS-Fuzz repo, and then running
|
||||
commands like this:
|
||||
|
||||
python infra/helper.py build_image systemd
|
||||
python infra/helper.py build_fuzzers --sanitizer memory systemd ../systemd
|
||||
python infra/helper.py run_fuzzer systemd fuzz-foo
|
||||
|
||||
If you find a bug that impacts the security of systemd, please follow the
|
||||
guidance in .github/CONTRIBUTING.md on how to report a security vulnerability.
|
||||
|
||||
For more details on building fuzzers and integrating with OSS-Fuzz, visit:
|
||||
|
||||
https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md
|
||||
|
||||
https://llvm.org/docs/LibFuzzer.html
|
||||
|
||||
https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md
|
||||
|
||||
https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/efficient_fuzzer.md
|
||||
@ -1,27 +0,0 @@
|
||||
Notes for translators
|
||||
=====================
|
||||
|
||||
systemd depends on gettext for multilingual support.
|
||||
In po/ directory you'll find the needed files.
|
||||
|
||||
POT (Portable Object Template)
|
||||
------------------------------
|
||||
A text file with .pot extension, with all the extracted labels from code.
|
||||
|
||||
To update the template:
|
||||
|
||||
$ cd systemd/
|
||||
$ ninja -C build systemd-pot
|
||||
|
||||
To start a new translation:
|
||||
|
||||
$ cd po/
|
||||
$ cp systemd.pot <YOUR-LANG-CODE>.po
|
||||
|
||||
Replace <YOUR-LANG-CODE> with the two-letters codes of ISO 639 standard.
|
||||
|
||||
PO (Portable Object)
|
||||
--------------------
|
||||
A text file with .po extension, with all the available labels and some additional
|
||||
metadata fields. Any editor is ok, but a good standard is 'poedit', a graphical
|
||||
application specifically designed for this kind of task.
|
||||
203
docs/AUTOMATIC_BOOT_ASSESSMENT.md
Normal file
203
docs/AUTOMATIC_BOOT_ASSESSMENT.md
Normal file
@ -0,0 +1,203 @@
|
||||
# Automatic Boot Assessment
|
||||
|
||||
systemd provides support for automatically reverting back to the previous
|
||||
version of the OS or kernel in case the system consistently fails to boot. This
|
||||
support is built into various of its components. When used together these
|
||||
components provide a complete solution on UEFI systems, built as add-on to the
|
||||
[Boot Loader
|
||||
Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION). However, the
|
||||
different components may also be used independently, and in combination with
|
||||
other software, to implement similar schemes, for example with other boot
|
||||
loaders or for non-UEFI systems. Here's a brief overview of the complete set of
|
||||
components:
|
||||
|
||||
* The
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
|
||||
boot loader optionally maintains a per-boot-loader-entry counter that is
|
||||
decreased by one on each attempt to boot the entry, prioritizing entries that
|
||||
have non-zero counters over those which already reached a counter of zero
|
||||
when choosing the entry to boot.
|
||||
|
||||
* The
|
||||
[`systemd-bless-boot.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-bless-boot.service.html)
|
||||
service automatically marks a boot loader entry, for which boot counting as
|
||||
mentioned above is enabled, as "good" when a boot has been determined to be
|
||||
successful, thus turning off boot counting for it.
|
||||
|
||||
* The
|
||||
[`systemd-bless-boot-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-bless-boot-generator.html)
|
||||
generator automatically pulls in `systemd-bless-boot.service` when use of
|
||||
`systemd-boot` with boot counting enabled is detected.
|
||||
|
||||
* The
|
||||
[`systemd-boot-check-no-failures.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-boot-check-no-failures.service.html)
|
||||
service is a simple health check tool that determines whether the boot
|
||||
completed successfully. When enabled it becomes an indirect dependency of
|
||||
`systemd-bless-boot.service` (by means of `boot-complete.target`, see
|
||||
below), ensuring that the boot will not be considered successful if there are
|
||||
any failed services.
|
||||
|
||||
* The `boot-complete.target` target unit (see
|
||||
[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html))
|
||||
serves as a generic extension point both for units that shall be considered
|
||||
necessary to consider a boot successful on one side (example:
|
||||
`systemd-boot-check-no-failures.service` as described above), and units that
|
||||
want to act only if the boot is successful on the other (example:
|
||||
`systemd-bless-boot.service` as described above).
|
||||
|
||||
* The
|
||||
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/kernel-install.html)
|
||||
script can optionally create boot loader entries that carry an initial boot
|
||||
counter (the initial counter is configurable in `/etc/kernel/tries`).
|
||||
|
||||
# Details
|
||||
|
||||
The boot counting data `systemd-boot` and `systemd-bless-boot.service`
|
||||
manage is stored in the name of the boot loader entries. If a boot loader entry
|
||||
file name contains `+` followed by one or two numbers (if two numbers, then
|
||||
those need to be separated by `-`) right before the `.conf` suffix, then boot
|
||||
counting is enabled for it. The first number is the "tries left" counter
|
||||
encoding how many attempts to boot this entry shall still be made. The second
|
||||
number is the "tries done" counter, encoding how many failed attempts to boot
|
||||
it have already been made. Each time a boot loader entry marked this way is
|
||||
booted the first counter is decreased by one, and the second one increased by
|
||||
one. (If the second counter is missing, then it is assumed to be equivalent to
|
||||
zero.) If the "tries left" counter is above zero the entry is still considered
|
||||
for booting (the entry's state is considered to be "indeterminate"), as soon as
|
||||
it reached zero the entry is not tried anymore (entry state "bad"). If the boot
|
||||
attempt completed successfully the entry's counters are removed from the name
|
||||
(entry state "good"), thus turning off boot counting for the future.
|
||||
|
||||
## Walkthrough
|
||||
|
||||
Here's an example walkthrough of how this all fits together.
|
||||
|
||||
1. The user runs `echo 3 > /etc/kernel/tries` to enable boot counting.
|
||||
|
||||
2. A new kernel is installed. `kernel-install` is used to generate a new boot
|
||||
loader entry file for it. Let's say the version string for the new kernel is
|
||||
`4.14.11-300.fc27.x86_64`, a new boot loader entry
|
||||
`/boot/loader/entries/4.14.11-300.fc27.x86_64+3.conf` is hence created.
|
||||
|
||||
3. The system is booted for the first time after the new kernel is
|
||||
installed. The boot loader now sees the `+3` counter in the entry file
|
||||
name. It hence renames the file to `4.14.11-300.fc27.x86_64+2-1.conf`
|
||||
indicating that at this point one attempt has started and thus only one less
|
||||
is left. After the rename completed the entry is booted as usual.
|
||||
|
||||
4. Let's say this attempt to boot fails. On the following boot the boot loader
|
||||
will hence see the `+2-1` tag in the name, and hence rename the entry file to
|
||||
`4.14.11-300.fc27.x86_64+1-2.conf`, and boot it.
|
||||
|
||||
5. Let's say the boot fails again. On the subsequent boot the loader hence will
|
||||
see the `+1-2` tag, and rename the file to
|
||||
`4.14.11-300.fc27.x86_64+0-3.conf` and boot it.
|
||||
|
||||
6. If this boot also fails, on the next boot the boot loader will see the the
|
||||
tag `+0-3`, i.e. the counter reached zero. At this point the entry will be
|
||||
considered "bad", and ordered to the end of the list of entries. The next
|
||||
newest boot entry is now tried, i.e. the system automatically reverted back
|
||||
to an earlier version.
|
||||
|
||||
The above describes the walkthrough when the selected boot entry continuously
|
||||
fails. Let's have a look at an alternative ending to this walkthrough. In this
|
||||
scenario the first 4 steps are the same as above:
|
||||
|
||||
1. *as above*
|
||||
|
||||
2. *as above*
|
||||
|
||||
3. *as above*
|
||||
|
||||
4. *as above*
|
||||
|
||||
5. Let's say the second boot succeeds. The kernel initializes properly, systemd
|
||||
is started and invokes all generators.
|
||||
|
||||
6. One of the generators started is `systemd-bless-boot-generator` which
|
||||
detects that boot counting is used. It hence pulls
|
||||
`systemd-bless-boot.service` into the initial transaction.
|
||||
|
||||
7. `systemd-bless-boot.service` is ordered after and `Requires=` the generic
|
||||
`boot-complete.target` unit. This unit is hence also pulled into the initial
|
||||
transaction.
|
||||
|
||||
8. The `boot-complete.target` unit is ordered after and pulls in various units
|
||||
that are required to succeed for the boot process to be considered
|
||||
successful. One such unit is `systemd-boot-check-no-failures.service`.
|
||||
|
||||
9. `systemd-boot-check-no-failures.service` is run after all its own
|
||||
dependencies completed, and assesses that the boot completed
|
||||
successfully. It hence exits cleanly.
|
||||
|
||||
10. This allows `boot-complete.target` to be reached. This signifies to the
|
||||
system that this boot attempt shall be considered successful.
|
||||
|
||||
11. Which in turn permits `systemd-bless-boot.service` to run. It now
|
||||
determines which boot loader entry file was used to boot the system, and
|
||||
renames it dropping the counter tag. Thus
|
||||
`4.14.11-300.fc27.x86_64+1-2.conf` is renamed to
|
||||
`4.14.11-300.fc27.x86_64.conf`. From this moment boot counting is turned
|
||||
off.
|
||||
|
||||
12. On the following boot (and all subsequent boots after that) the entry is
|
||||
now seen with boot counting turned off, no further renaming takes place.
|
||||
|
||||
# How to adapt this scheme to other setups
|
||||
|
||||
Of the stack described above many components may be replaced or augmented. Here
|
||||
are a couple of recommendations.
|
||||
|
||||
1. To support alternative boot loaders in place of `systemd-boot` two scenarios
|
||||
are recommended:
|
||||
|
||||
a. Boot loaders already implementing the Boot Loader Specification can simply
|
||||
implement an equivalent file rename based logic, and thus integrate fully
|
||||
with the rest of the stack.
|
||||
|
||||
b. Boot loaders that want to implement boot counting and store the counters
|
||||
elsewhere can provide their own replacements for
|
||||
`systemd-bless-boot.service` and `systemd-bless-boot-generator`, but should
|
||||
continue to use `boot-complete.target` and thus support any services
|
||||
ordered before that.
|
||||
|
||||
2. To support additional components that shall succeed before the boot is
|
||||
considered successful, simply place them in units (if they aren't already)
|
||||
and order them before the generic `boot-complete.target` target unit,
|
||||
combined with `Requires=` dependencies from the target, so that the target
|
||||
cannot be reached when any of the units fail. You may add any number of
|
||||
units like this, and only if they all succeed the boot entry is marked as
|
||||
good. Note that the target unit shall pull in these boot checking units, not
|
||||
the other way around.
|
||||
|
||||
3. To support additional components that shall only run on boot success, simply
|
||||
wrap them in a unit and order them after `boot-complete.target`, pulling it
|
||||
in.
|
||||
|
||||
# FAQ
|
||||
|
||||
1. *Why do you use file renames to store the counter? Why not a regular file?*
|
||||
— Mainly two reasons: it's relatively likely that renames can be implemented
|
||||
atomically even in simpler file systems, while writing to file contents has
|
||||
a much bigger chance to be result in incomplete or corrupt data, as renaming
|
||||
generally avoids allocating or releasing data blocks. Moreover it has the
|
||||
benefit that the boot count metadata is directly attached to the boot loader
|
||||
entry file, and thus the lifecycle of the metadata and the entry itself are
|
||||
bound together. This means no additional clean-up needs to take place to
|
||||
drop the boot loader counting information for an entry when it is removed.
|
||||
|
||||
2. *Why not use EFI variables for storing the boot counter?* — The memory chips
|
||||
used to back the persistent EFI variables are generally not of the highest
|
||||
quality, hence shouldn't be written to more than necessary. This means we
|
||||
can't really use it for changes made regularly during boot, but can use it
|
||||
only for seldom made configuration changes.
|
||||
|
||||
3. *I have a service which — when it fails — should immediately cause a
|
||||
reboot. How does that fit in with the above?* — Well, that's orthogonal to
|
||||
the above, please use `FailureAction=` in the unit file for this.
|
||||
|
||||
4. *Under some condition I want to mark the current boot loader entry as bad
|
||||
right-away, so that it never is tried again, how do I do that?* — You may
|
||||
invoke `/usr/lib/systemd/systemd-bless-boot bad` at any time to mark the
|
||||
current boot loader entry as "bad" right-away so that it isn't tried again
|
||||
on later boots.
|
||||
63
docs/BLOCK_DEVICE_LOCKING.md
Normal file
63
docs/BLOCK_DEVICE_LOCKING.md
Normal file
@ -0,0 +1,63 @@
|
||||
# Locking Block Device Access
|
||||
|
||||
*TL;DR: Use BSD file locks
|
||||
[(`flock(2)`)](http://man7.org/linux/man-pages/man2/flock.2.html) on block
|
||||
device nodes to synchronize access for partitioning and file system formatting
|
||||
tools.*
|
||||
|
||||
`systemd-udevd` probes all block devices showing up for file system superblock
|
||||
and partition table information (utilizing `libblkid`). If another program
|
||||
concurrently modifies a superblock or partition table this probing might be
|
||||
affected, which is bad in itself, but also might in turn result in undesired
|
||||
effects in programs subscribing to `udev` events.
|
||||
|
||||
Applications manipulating a block device can temporarily stop `systemd-udevd`
|
||||
from processing rules on it — and thus bar it from probing the device — by
|
||||
taking a BSD file lock on the block device node. Specifically, whenever
|
||||
`systemd-udevd` starts processing a block device it takes a `LOCK_SH|LOCK_NB`
|
||||
lock using [`flock(2)`](http://man7.org/linux/man-pages/man2/flock.2.html) on
|
||||
the main block device (i.e. never on any partition block device, but on the
|
||||
device the partition belongs to). If this lock cannot be taken (i.e. `flock()`
|
||||
returns `EBUSY`), it refrains from processing the device. If it manages to take
|
||||
the lock it is kept for the entire time the device is processed.
|
||||
|
||||
Note that `systemd-udevd` also watches all block device nodes it manages for
|
||||
`inotify()` `IN_CLOSE` events: whenever such an event is seen, this is used as
|
||||
trigger to re-run the rule-set for the device.
|
||||
|
||||
These two concepts allow tools such as disk partitioners or file system
|
||||
formatting tools to safely and easily take exclusive ownership of a block
|
||||
device while operating: before starting work on the block device, they should
|
||||
take an `LOCK_EX` lock on it. This has two effects: first of all, in case
|
||||
`systemd-udevd` is still processing the device the tool will wait for it to
|
||||
finish. Second, after the lock is taken, it can be sure that that
|
||||
`systemd-udevd` will refrain from processing the block device, and thus all
|
||||
other client applications subscribed to it won't get device notifications from
|
||||
potentially half-written data either. After the operation is complete the
|
||||
partitioner/formatter can simply close the device node. This has two effects:
|
||||
it implicitly releases the lock, so that `systemd-udevd` can process events on
|
||||
the device node again. Secondly, it results an `IN_CLOSE` event, which causes
|
||||
`systemd-udevd` to immediately re-process the device — seeing all changes the
|
||||
tool made — and notify subscribed clients about it.
|
||||
|
||||
Besides synchronizing block device access between `systemd-udevd` and such
|
||||
tools this scheme may also be used to synchronize access between those tools
|
||||
themselves. However, do note that `flock()` locks are advisory only. This means
|
||||
if one tool honours this scheme and another tool does not, they will of course
|
||||
not be synchronized properly, and might interfere with each other's work.
|
||||
|
||||
Note that the file locks follow the usual access semantics of BSD locks: since
|
||||
`systemd-udevd` never writes to such block devices it only takes a `LOCK_SH`
|
||||
*shared* lock. A program intending to make changes to the block device should
|
||||
take a `LOCK_EX` *exclusive* lock instead. For further details, see the
|
||||
`flock(2)` man page.
|
||||
|
||||
And please keep in mind: BSD file locks (`flock()`) and POSIX file locks
|
||||
(`lockf()`, `F_SETLK`, …) are different concepts, and in their effect
|
||||
orthogonal. The scheme discussed above uses the former and not the latter,
|
||||
because these types of locks more closely match the required semantics.
|
||||
|
||||
Summarizing: it is recommended to take `LOCK_EX` BSD file locks when
|
||||
manipulating block devices in all tools that change file system block devices
|
||||
(`mkfs`, `fsck`, …) or partition tables (`fdisk`, `parted`, …), right after
|
||||
opening the node.
|
||||
114
docs/BOOT_LOADER_INTERFACE.md
Normal file
114
docs/BOOT_LOADER_INTERFACE.md
Normal file
@ -0,0 +1,114 @@
|
||||
# The Boot Loader Interface
|
||||
|
||||
systemd can interface with the boot loader to receive performance data and
|
||||
other information, and pass control information. This is only supported on EFI
|
||||
systems. Data is transferred between the boot loader and systemd in EFI
|
||||
variables. All EFI variables use the vendor UUID
|
||||
`4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`.
|
||||
|
||||
* The EFI Variable `LoaderTimeInitUSec` contains the timestamp in microseconds
|
||||
when the loader was initialized. This value is the time spent in the firmware
|
||||
for initialization, it is formatted as numeric, NUL-terminated, decimal
|
||||
string, in UTF-16.
|
||||
|
||||
* The EFI Variable `LoaderTimeExecUSec` contains the timestamp in microseconds
|
||||
when the loader finished its work and is about to execute the kernel. The
|
||||
time spent in the loader is the difference between `LoaderTimeExecUSec` and
|
||||
`LoaderTimeInitUSec`. This value is formatted the same way as
|
||||
`LoaderTimeInitUSec`.
|
||||
|
||||
* The EFI variable `LoaderDevicePartUUID` contains the partition GUID of the
|
||||
ESP the boot loader was run from formatted as NUL-terminated UTF16 string, in
|
||||
normal GUID syntax.
|
||||
|
||||
* The EFI variable `LoaderConfigTimeout` contains the boot menu timeout
|
||||
currently in use. It may be modified both by the boot loader and by the
|
||||
host. The value should be formatted as numeric, NUL-terminated, decimal
|
||||
string, in UTF-16. The time is specified in µs.
|
||||
|
||||
* Similarly, the EFI variable `LoaderConfigTimeoutOneShot` contains a boot menu
|
||||
timeout for a single following boot. It is set by the OS in order to request
|
||||
display of the boot menu on the following boot. When set overrides
|
||||
`LoaderConfigTimeout`. It is removed automatically after being read by the
|
||||
boot loader, to ensure it only takes effect a single time. This value is
|
||||
formatted the same way as `LoaderConfigTimeout`. If set to `0` the boot menu
|
||||
timeout is turned off, and the menu is shown indefinitely.
|
||||
|
||||
* The EFI variable `LoaderEntries` may contain a series of boot loader entry
|
||||
identifiers, one after the other, each individually NUL terminated. This may
|
||||
be used to let the OS know which boot menu entries were discovered by the
|
||||
boot loader. A boot loader entry identifier should be a short, non-empty
|
||||
alphanumeric string (possibly containing `-`, too). The list should be in the
|
||||
order the entries are shown on screen during boot. See below regarding a
|
||||
recommended vocabulary for boot loader entry identifiers.
|
||||
|
||||
* The EFI variable `LoaderEntryDefault` contains the default boot loader entry
|
||||
to use. It contains a NUL-terminated boot loader entry identifier.
|
||||
|
||||
* Similarly, the EFI variable `LoaderEntryOneShot` contains the default boot
|
||||
loader entry to use for a single following boot. It is set by the OS in order
|
||||
to request booting into a specific menu entry on the following boot. When set
|
||||
overrides `LoaderEntryDefault`. It is removed automatically after being read
|
||||
by the boot loader, to ensure it only takes effect a single time. This value
|
||||
is formatted the same way as `LoaderEntryDefault`.
|
||||
|
||||
* The EFI variable `LoaderEntrySelected` contains the boot loader entry
|
||||
identifier that was booted. It is set by the boot loader and read by
|
||||
the OS in order to identify which entry has been used for the current boot.
|
||||
|
||||
* The EFI variable `LoaderFeatures` contains a 64bit unsigned integer with a
|
||||
number of flags bits that are set by the boot loader and passed to the OS and
|
||||
indicate the features the boot loader supports. Specifically, the following
|
||||
bits are defined:
|
||||
|
||||
* `1 << 0` → The boot loader honours `LoaderConfigTimeout` when set.
|
||||
* `1 << 1` → The boot loader honours `LoaderConfigTimeoutOneShot` when set.
|
||||
* `1 << 2` → The boot loader honours `LoaderEntryDefault` when set.
|
||||
* `1 << 3` → The boot loader honours `LoaderEntryOneShot` when set.
|
||||
* `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT).
|
||||
|
||||
If `LoaderTimeInitUSec` and `LoaderTimeExecUSec` are set, `systemd-analyze`
|
||||
will include them in its boot-time analysis. If `LoaderDevicePartUUID` is set,
|
||||
systemd will mount the ESP that was used for the boot to `/boot`, but only if
|
||||
that directory is empty, and only if no other file systems are mounted
|
||||
there. The `systemctl reboot --boot-loader-entry=…` and `systemctl reboot
|
||||
--boot-loader-menu=…` commands rely on the `LoaderFeatures` ,
|
||||
`LoaderConfigTimeoutOneShot`, `LoaderEntries`, `LoaderEntryOneShot` variables.
|
||||
|
||||
## Boot Loader Entry Identifiers
|
||||
|
||||
While boot loader entries may be named relatively freely, it's highly
|
||||
recommended to follow the following rules when picking identifiers for the
|
||||
entries, so that programs (and users) can derive basic context and meaning from
|
||||
the identifiers as passed in `LoaderEntries`, `LoaderEntryDefault`,
|
||||
`LoaderEntryOneShot`, `LoaderEntrySelected`, and possibly show nicely localized
|
||||
names for them in UIs.
|
||||
|
||||
1. When boot loader entries are defined through [Boot Loader
|
||||
Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION) drop-in files
|
||||
the identifier should be derived directly from the drop-in snippet name, but
|
||||
with the `.conf` (or `.efi` in case of Type #2 entries) suffix removed.
|
||||
|
||||
2. Entries automatically discovered by the boot loader (as opposed to being
|
||||
configured in configuration files) should generally have an identifier
|
||||
prefixed with `auto-`.
|
||||
|
||||
3. Boot menu entries referring to Microsoft Windows installations should either
|
||||
use the identifier `windows` or use the `windows-` prefix for the
|
||||
identifier. If a menu entry is automatically discovered, it should be
|
||||
prefixed with `auto-`, see above (Example: this means an automatically
|
||||
discovered Windows installation might have the identifier `auto-windows` or
|
||||
`auto-windows-10` or so.).
|
||||
|
||||
4. Similar, boot menu entries referring to Apple MacOS X installations should
|
||||
use the identifier `osx` or one that is prefixed with `osx-`. If such an
|
||||
entry is automatically discovered by the boot loader use `auto-osx` as
|
||||
identifier, or `auto-osx-` as prefix for the identifier, see above.
|
||||
|
||||
5. If a boot menu entry encapsulates the EFI shell program, it should use the
|
||||
identifier `efi-shell` (or when automatically discovered: `auto-efi-shell`,
|
||||
see above).
|
||||
|
||||
6. If a boot menu entry encapsulates a reboot into EFI firmware setup feature,
|
||||
it should use the identifier `reboot-to-firmware-setup` (or
|
||||
`auto-reboot-to-firmware-setup` in case it is automatically discovered).
|
||||
@ -15,9 +15,9 @@ Of course, without this specification things already work mostly fine. But here'
|
||||
|
||||
* To make the boot more robust, as no explicit rewriting of configuration files is required any more
|
||||
* To improve dual-boot scenarios. Currently, multiple Linux installations tend to fight over which boot loader becomes the primary one in possession of the MBR, and only that one installation can then update the boot loader configuration of it freely. Other Linux installs have to be manually configured to never touch the MBR and instead install a chain-loaded boot loader in their own partition headers. In this new scheme as all installations share a loader directory no manual configuration has to take place, and all participants implicitly cooperate due to removal of name collisions and can install/remove their own boot menu entries at free will, without interfering with the entries of other installed operating systems.
|
||||
* Drop-in directories are otherwise now pretty ubiquitous on Linux as an easy way to extend configuration without having to edit, regenerate or manipulate configuration files. For the sake of uniformity we should do the same for extending the boot menu.
|
||||
* Drop-in directories are otherwise now pretty ubiquitous on Linux as an easy way to extend configuration without having to edit, regenerate or manipulate configuration files. For the sake of uniformity, we should do the same for extending the boot menu.
|
||||
* Userspace code can sanely parse boot loader configuration which is essential with modern BIOSes which do not necessarily initialize USB keyboards anymore during boot, which makes boot menus hard to reach for the user. If userspace code can parse the boot loader configuration, too, this allows for UIs that can select a boot menu item to boot into, before rebooting the machine, thus not requiring interactivity during early boot.
|
||||
* To unify and thus simplify configuration of the various boot loaders around, which makes configuration of the boot loading process easier for users, administrators and developers alike
|
||||
* To unify and thus simplify configuration of the various boot loaders around, which makes configuration of the boot loading process easier for users, administrators and developers alike.
|
||||
* For boot loaders with configuration _scripts_ such as grub2, adopting this spec allows for mostly static scripts that are generated only once at first installation, but then do not need to be updated anymore as that is done via drop-in files exclusively.
|
||||
|
||||
## Why not simply rely on the EFI boot menu logic?
|
||||
@ -25,7 +25,7 @@ Of course, without this specification things already work mostly fine. But here'
|
||||
The EFI specification provides a boot options logic that can offer similar functionality. Here's why we think that it is not enough for our uses:
|
||||
|
||||
* The various EFI implementations implement the boot order/boot item logic to different levels. Some firmware implementations do not offer a boot menu at all and instead unconditionally follow the EFI boot order, booting the first item that is working.
|
||||
* If the firmware setup is used to reset all data usually all EFI boot entries are lost, making the system entirely unbootable, as the firmware setups generally do not offer a UI to define additional boot items. By placing the menu item information on disk it is always available, regardless if the BIOS setup data is lost.
|
||||
* If the firmware setup is used to reset all data usually all EFI boot entries are lost, making the system entirely unbootable, as the firmware setups generally do not offer a UI to define additional boot items. By placing the menu item information on disk, it is always available, regardless if the BIOS setup data is lost.
|
||||
* Harddisk images should be moveable between machines and be bootable without requiring explicit EFI variables to be set. This also requires that the list of boot options is defined on disk, and not in EFI variables alone.
|
||||
* EFI is not universal yet (especially on non-x86 platforms), this specification is useful both for EFI and non-EFI boot loaders.
|
||||
* Many EFI systems disable USB support during early boot to optimize boot times, thus making keyboard input unavailable in the EFI menu. It is thus useful if the OS UI has a standardized way to discover available boot options which can be booted to.
|
||||
@ -36,61 +36,89 @@ Everything described below is located on a placeholder file system `$BOOT`. The
|
||||
|
||||
* On disks with MBR disk labels
|
||||
* If the OS is installed on a disk with MBR disk label, and a partition with the MBR type id of 0xEA already exists it should be used as `$BOOT`.
|
||||
* Otherwise, if the the OS is installed on a disk with MBR disk label, a new partition with MBR type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as `$BOOT`.
|
||||
* Otherwise, if the OS is installed on a disk with MBR disk label, a new partition with MBR type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as `$BOOT`.
|
||||
* On disks with GPT disk labels
|
||||
* If the OS is installed on a disk with GPT disk label, and a partition with the GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 already exists, it should be used as `$BOOT`.
|
||||
* Otherwise, if the OS is installed on a disk with GPT disk label, and an ESP partition (i.e. with the GPT type UID of c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large enough (let's say 250MB) and otherwise qualifies, it should be used as `$BOOT`.
|
||||
* Otherwise, if the OS is installed on a disk with GPT disk label, and if the ESP partition already exists but is too small, a new suitably sized (let's say 500MB) partition with GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should be used as `$BOOT`.
|
||||
* Otherwise, if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as `$BOOT`.
|
||||
|
||||
This placeholder file system shall be determined during _installation time_, and an fstab entry maybe be created. It should be mounted to either /boot or /efi. Additional locations like /boot/efi, with /boot being a separate file system, might be supported by implementations. This is not recommended because the mounting of `$BOOT` is then dependent on and requires the mounting of the intermediate file system.
|
||||
This placeholder file system shall be determined during _installation time_, and an fstab entry may be created. It should be mounted to either `/boot/` or `/efi/`. Additional locations like `/boot/efi/`, with `/boot/` being a separate file system, might be supported by implementations. This is not recommended because the mounting of `$BOOT` is then dependent on and requires the mounting of the intermediate file system.
|
||||
|
||||
**Note:** _`$BOOT` should be considered **shared** among all OS installations of a system. Instead of maintaining one `$BOOT` per installed OS (as `/boot` was traditionally handled), all installed OS share the same place to drop in their boot-time configuration._
|
||||
**Note:** _`$BOOT` should be considered **shared** among all OS installations of a system. Instead of maintaining one `$BOOT` per installed OS (as `/boot/` was traditionally handled), all installed OS share the same place to drop in their boot-time configuration._
|
||||
|
||||
`$BOOT` must be a VFAT (16 or 32) file system. Other file system types should not be used. Applications accessing `$BOOT` should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported.
|
||||
For systems where the firmware is able to read file systems directly, `$BOOT` must be a file system readable by the firmware. For other systems, `$BOOT` must be a VFAT (16 or 32) file system. Applications accessing `$BOOT` should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported.
|
||||
|
||||
### Boot loader specification entries
|
||||
This specification defines two types of boot loader entries. The first type is
|
||||
text based, very simple and suitable for a variety of firmware, architecture
|
||||
and image types ("Type #1"). The second type is specific to EFI, but allows
|
||||
single-file images that embed all metadata in the kernel binary itself, which
|
||||
is useful to cryptographically sign them as one file for the purpose of
|
||||
SecureBoot ("Type #2").
|
||||
|
||||
Not all boot loader entries will apply to all systems. For example, Type #1
|
||||
entries that use the `efi` key and all Type #2 entries only apply to EFI
|
||||
systems. Entries using the `architecture` key might specify an architecture that
|
||||
doesn't match the local one. Boot loaders should ignore all entries that don't
|
||||
match the local platform and what the boot loader can support, and hide them
|
||||
from the user. Only entries matching the feature set of boot loader and system
|
||||
shall be considered and displayed. This allows image builders to put together
|
||||
images that transparently support multiple different architectures.
|
||||
|
||||
### Type #1 Boot Loader Specification Entries
|
||||
|
||||
We define two directories below `$BOOT`:
|
||||
|
||||
* `$BOOT/loader/` is the directory containing all files defined by this specification
|
||||
* `$BOOT/loader/` is the directory containing all files needed for Type #1 entries
|
||||
* `$BOOT/loader/entries/` is the directory containing the drop-in snippets. This directory contains one `.conf` file for each boot menu item.
|
||||
|
||||
**Note:** _In all cases the /loader directory should be located directly in the root of the file system. Specifically, if `$BOOT` is the ESP, then /loader directory should be located directly in the root directory of the ESP, and not in the EFI/ subdirectory._
|
||||
**Note:** _In all cases the `/loader/` directory should be located directly in the root of the file system. Specifically, if `$BOOT` is the ESP, then `/loader/` directory should be located directly in the root directory of the ESP, and not in the `/EFI/` subdirectory._
|
||||
|
||||
Inside the `$BOOT/loader/entries/` directory each OS vendor may drop one or more configuration snippets with the suffix ".conf", one for each boot menu item. The file name of the file is used for identification of the boot item, but shall never be presented to the user in the UI. The file name may be chosen freely but should be unique enough to avoid clashes between OS installations. More specifically it is suggested to include the machine ID (`/etc/machine-id` or the D-Bus machine ID for OSes that lack `/etc/machine-id`), the kernel version (as returned by `uname -r`) and an OS identifier (The ID field of `/etc/os-release`). Example: `$BOOT/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf`.
|
||||
Inside the `$BOOT/loader/entries/` directory each OS vendor may drop one or more configuration snippets with the suffix ".conf", one for each boot menu item. The file name of the file is used for identification of the boot item but shall never be presented to the user in the UI. The file name may be chosen freely but should be unique enough to avoid clashes between OS installations. More specifically it is suggested to include the machine ID (`/etc/machine-id` or the D-Bus machine ID for OSes that lack `/etc/machine-id`), the kernel version (as returned by `uname -r`) and an OS identifier (The ID field of `/etc/os-release`). Example: `$BOOT/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf`.
|
||||
|
||||
These configuration snippets shall be Unix-style text files (i.e. line separation with a single newline character), in the UTF-8 encoding. The configuration snippets are loosely inspired on Grub1's configuration syntax. Lines beginning with '#' shall be ignored and used for commenting. The first word of a line is used as key, and shall be separated by a space from its value. The following keys are known:
|
||||
These configuration snippets shall be Unix-style text files (i.e. line separation with a single newline character), in the UTF-8 encoding. The configuration snippets are loosely inspired on Grub1's configuration syntax. Lines beginning with '#' shall be ignored and used for commenting. The first word of a line is used as key and shall be separated by a space from its value. The following keys are known:
|
||||
|
||||
* `title` shall contain a human readable title string for this menu item. This will be displayed in the boot menu for the item. It is a good idea to initialize this from the `PRETTY_NAME` of `/etc/os-release`. This name should be descriptive and does not have to be unique. If a boot loader discovers two entries with the same title it is a good idea to show more than just the raw title in the UI, for example by appending the `version` field. This field is optional. Example: "Fedora 18 (Spherical Cow)".
|
||||
* `version` shall contain a human readable version string for this menu item. This is usually the kernel version and is intended for use by OSes to install multiple kernel versions at the same time with the same `title` field. This field shall be in a syntax that is useful for Debian-style version sorts, so that the boot loader UI can determine the newest version easily and show it first or preselect it automatically. This field is optional. Example: `3.7.2-201.fc18.x86_64`
|
||||
* `machine-id` shall contain the machine ID of the OS `/etc/machine-id`. This is useful for boot loaders and applications to filter out boot entries, for example to show only a single newest kernel per OS, or to group items by OS, or to maybe filter out the currently booted OS in UIs that want to show only other installed operating systems. This ID shall be formatted as 32 lower case hexadecimal characters (i.e. without any UUID formatting). This key is optional. Example: `4098b3f648d74c13b1f04ccfba7798e8`
|
||||
* `linux` refers to the kernel to spawn, and shall be a path relative to the `$BOOT` directory. It is recommended that every distribution creates a machine id and version specific subdirectory below `$BOOT` and places its kernels and initial RAM disk images there. Example: `/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux`.
|
||||
* `initrd` refers to the initrd to use when executing the kernel. This also shall be a path relative to the `$BOOT` directory. This key is optional. This key may appear more than once in which case all specified images are used, in the order they are listed. Example: `6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd`
|
||||
* `efi` to spawn arbitrary EFI programs. This also takes a path relative to `$BOOT`. This key is only available on EFI systems.
|
||||
* `options` shall contain kernel parameters to pass to the Linux kernel to spawn. This key is optional.
|
||||
* `version` shall contain a human readable version string for this menu item. This is usually the kernel version and is intended for use by OSes to install multiple kernel versions at the same time with the same `title` field. This field shall be in a syntax that is useful for Debian-style version sorts, so that the boot loader UI can determine the newest version easily and show it first or preselect it automatically. This field is optional. Example: `3.7.2-201.fc18.x86_64`.
|
||||
* `machine-id` shall contain the machine ID of the OS `/etc/machine-id`. This is useful for boot loaders and applications to filter out boot entries, for example to show only a single newest kernel per OS, or to group items by OS, or to maybe filter out the currently booted OS in UIs that want to show only other installed operating systems. This ID shall be formatted as 32 lower case hexadecimal characters (i.e. without any UUID formatting). This key is optional. Example: `4098b3f648d74c13b1f04ccfba7798e8`.
|
||||
* `linux` refers to the Linux kernel to spawn and shall be a path relative to the `$BOOT` directory. It is recommended that every distribution creates a machine id and version specific subdirectory below `$BOOT` and places its kernels and initial RAM disk images there. Example: `/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux`.
|
||||
* `initrd` refers to the initrd to use when executing the kernel. This also shall be a path relative to the `$BOOT` directory. This key is optional. This key may appear more than once in which case all specified images are used, in the order they are listed. Example: `6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd`.
|
||||
* `efi` refers to an arbitrary EFI program. This also takes a path relative to `$BOOT`. If this key is set, and the system is not an EFI system this entry should be hidden.
|
||||
* `options` shall contain kernel parameters to pass to the Linux kernel to spawn. This key is optional and may appear more than once in which case all specified parameters are used in the order they are listed.
|
||||
* `devicetree` refers to the binary device tree to use when executing the
|
||||
kernel. This also shall be a path relative to the `$BOOT` directory. This
|
||||
key is optional. Example: `6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.armv7hl/tegra20-paz00.dtb`
|
||||
* `architecture` refers to the UEFI architecture this entry is defined for. If specified and this does not match the local UEFI system architecture the entry is hidden.
|
||||
key is optional. Example: `6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.armv7hl/tegra20-paz00.dtb`.
|
||||
* `architecture` refers to the architecture this entry is defined for. The argument should be an architecture identifier, using the architecture vocabulary defined by the EFI specification (i.e. `IA32`, `x64`, `IA64`, `ARM`, `AA64`, …). If specified and this does not match (case insensitively) the local system architecture this entry should be hidden.
|
||||
|
||||
Each configuration drop-in snippet must include at least a `linux` or an `efi` key, and is otherwise not valid. Here's an example for a complete drop-in file:
|
||||
Each configuration drop-in snippet must include at least a `linux` or an `efi` key and is otherwise not valid. Here's an example for a complete drop-in file:
|
||||
|
||||
# /boot/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf
|
||||
title Fedora 19 (Rawhide)
|
||||
version 3.8.0-2.fc19.x86_64
|
||||
machine-id 6a9857a393724b7a981ebb5b8495b9ea
|
||||
options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2
|
||||
linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
|
||||
initrd /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd
|
||||
title Fedora 19 (Rawhide)
|
||||
version 3.8.0-2.fc19.x86_64
|
||||
machine-id 6a9857a393724b7a981ebb5b8495b9ea
|
||||
options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2
|
||||
architecture x64
|
||||
linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
|
||||
initrd /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd
|
||||
|
||||
On EFI systems all kernel images shall be EFI images. In order to be compatible with EFI systems it is highly recommended only to install EFI kernel images, even on non-EFI systems, if that's applicable and supported on the specific architecture.
|
||||
On EFI systems all Linux kernel images should be EFI images. In order to increase compatibility with EFI systems it is highly recommended only to install EFI kernel images, even on non-EFI systems, if that's applicable and supported on the specific architecture.
|
||||
|
||||
Note that these configuration snippets may only reference kernels (and EFI programs) that reside on the same file system as the configuration snippets, i.e. everything referenced must be contained in the same file system. This is by design, as referencing other partitions or devices would require a non-trivial language for denoting device paths. If kernels/initrds are to be read from other partitions/disks the boot loader can do this in its own native configuration, using its own specific device path language, and this is out of focus for this specification. More specifically, on non-EFI systems configuration snippets following this specification cannot be used to spawn other operating systems (such as Windows).
|
||||
|
||||
### Unified kernel images
|
||||
### Type #2 EFI Unified Kernel Images
|
||||
|
||||
A unified kernel image is a single UEFI executable combining an UEFI stub loader, a kernel image, an initramfs image, and the kernel command line. See the description of the `--uefi` option in [dracut(8)](http://man7.org/linux/man-pages/man8/dracut.8.html). Such images will be searched for under `$BOOT/EFI/Linux`, and must have the extension `.efi`.
|
||||
A unified kernel image is a single EFI PE executable combining an EFI stub
|
||||
loader, a kernel image, an initramfs image, and the kernel command line. See
|
||||
the description of the `--uefi` option in
|
||||
[dracut(8)](http://man7.org/linux/man-pages/man8/dracut.8.html). Such unified
|
||||
images will be searched for under `$BOOT/EFI/Linux/` and must have the
|
||||
extension `.efi`. Support for images of this type is of course specific to
|
||||
systems with EFI firmware. Ignore this section if you work on systems not
|
||||
supporting EFI.
|
||||
|
||||
Images of this type have the advantage that all metadata and payload that makes
|
||||
up the boot entry is monopolized in a single PE file that can be signed
|
||||
cryptographically as one for the purpose of EFI SecureBoot.
|
||||
|
||||
A valid unified kernel image must contain two PE sections:
|
||||
|
||||
@ -99,7 +127,7 @@ A valid unified kernel image must contain two PE sections:
|
||||
|
||||
The `PRETTY_NAME=` and `VERSION_ID=` fields in the embedded os-release file are used the same as `title` and `version` in the "boot loader specification" entries. The `.cmdline` section is used instead of the `options` field. `linux` and `initrd` fields are not necessary, and there is no counterpart for the `machine-id` field.
|
||||
|
||||
Any such images shall be added to the list of valid boot entries.
|
||||
On EFI, any such images shall be added to the list of valid boot entries.
|
||||
|
||||
### Additional notes
|
||||
|
||||
@ -112,23 +140,40 @@ Note that all paths used in the configuration snippets use a Unix-style "/" as p
|
||||
|
||||
## Logic
|
||||
|
||||
A _boot loader_ needs a file system driver to discover and read `$BOOT`, then simply reads all files `$BOOT/loader/entries/*.conf`, and populates its boot menu with this. It then extends this with any unified kernel images found in `$BOOT/EFI/Linux`. It may also add additional entries, for example "Reboot into firmware". Optionally it may sort the menu based on the `machine-id` and `version` fields, and possibly others. It uses the file name to identify specific items, for example in case it supports storing away default entry information somewhere. A boot loader should generally not modify these files.
|
||||
A _boot loader_ needs a file system driver to discover and read `$BOOT`, then
|
||||
simply reads all files `$BOOT/loader/entries/*.conf`, and populates its boot
|
||||
menu with this. On EFI, it then extends this with any unified kernel images
|
||||
found in `$BOOT/EFI/Linux/*.efi`. It may also add additional entries, for
|
||||
example a "Reboot into firmware" option. Optionally it may sort the menu based
|
||||
on the `machine-id` and `version` fields, and possibly others. It uses the file
|
||||
name to identify specific items, for example in case it supports storing away
|
||||
default entry information somewhere. A boot loader should generally not modify
|
||||
these files.
|
||||
|
||||
For "boot loader specification" entries, the _kernel package installer_ installs the kernel and initrd images to `$BOOT` (it is recommended to place these files in a vendor and OS and installation specific directory) and then generates a configuration snippet for it, placing this in `$BOOT/loader/entries/xyz.conf`, with xyz as concatenation of machine id and version information (see above). The files created by a kernel package are private property of the kernel package, and should be removed along with it.
|
||||
For "Boot Loader Specification Entries" (Type #1), the _kernel package
|
||||
installer_ installs the kernel and initrd images to `$BOOT` (it is recommended
|
||||
to place these files in a vendor and OS and installation specific directory)
|
||||
and then generates a configuration snippet for it, placing this in
|
||||
`$BOOT/loader/entries/xyz.conf`, with xyz as concatenation of machine id and
|
||||
version information (see above). The files created by a kernel package are
|
||||
private property of the kernel package and should be removed along with it.
|
||||
|
||||
For "unified kernel images", the _kernel install_ creates the combined image and drops it into `$BOOT/EFI/Linux`. This file is also private property of the kernel package, and should be removed along with it.
|
||||
For "EFI Unified Kernel Images" (Type #2), the vendor or kernel package
|
||||
installer creates the combined image and drops it into `$BOOT/EFI/Linux/`. This
|
||||
file is also private property of the kernel package and should be removed along
|
||||
with it.
|
||||
|
||||
A _UI application_ intended to show available boot options shall operate similar to a boot loader, but might apply additional filters, for example by filtering out the booted OS via the machine ID, or by suppressing all but the newest kernel versions.
|
||||
|
||||
An _OS installer_ picks the right place for `$BOOT` as defined above (possibly creating a partition and file system for it), and pre-creates the `/loader/entries/` directory in it. It then installs an appropriate boot loader that can read these snippets. Finally it installs one or more kernel packages.
|
||||
An _OS installer_ picks the right place for `$BOOT` as defined above (possibly creating a partition and file system for it) and pre-creates the `/loader/entries/` directory in it. It then installs an appropriate boot loader that can read these snippets. Finally, it installs one or more kernel packages.
|
||||
|
||||
|
||||
## Out of Focus
|
||||
|
||||
There are a couple of items that are out of focus for this specifications:
|
||||
There are a couple of items that are out of focus for this specification:
|
||||
|
||||
* If userspace can figure out the available boot options, then this is only useful so much: we'd still need to come up with a way how userspace could communicate to the boot loader the default boot loader entry temporarily or persistently. Defining a common scheme for this is certainly a good idea, but out of focus for this specifications.
|
||||
* This specifications is just about "Free" Operating systems. Hooking in other operating systems (like Windows, MacOS) into the boot menu is a different story, and should probably happen outside of this specification. For example, boot loaders might choose to detect other available OSes dynamically at runtime without explicit configuration (like <strike>Gummiboot</strike> systemd-boot does it), or via native configuration (for example via explicit Grub2 configuration generated once at installation).
|
||||
* If userspace can figure out the available boot options, then this is only useful so much: we'd still need to come up with a way how userspace could communicate to the boot loader the default boot loader entry temporarily or persistently. Defining a common scheme for this is certainly a good idea, but out of focus for this specification.
|
||||
* This specification is just about "Free" Operating systems. Hooking in other operating systems (like Windows and macOS) into the boot menu is a different story and should probably happen outside of this specification. For example, boot loaders might choose to detect other available OSes dynamically at runtime without explicit configuration (like `systemd-boot` does it), or via native configuration (for example via explicit Grub2 configuration generated once at installation).
|
||||
* This specification leaves undefined what to do about systems which are upgraded from an OS that does not implement this specification. As the previous boot loader logic was largely handled by in distribution-specific ways we probably should leave the upgrade path (and whether there actually is one) to the distributions. The simplest solution might be to simply continue with the old scheme for old installations and use this new scheme only for new installations.
|
||||
|
||||
|
||||
@ -136,5 +181,3 @@ There are a couple of items that are out of focus for this specifications:
|
||||
|
||||
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
|
||||
[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html)
|
||||
|
||||
[Obsolete patch adding Boot Loader Specification support to GNU grub 2](http://pkgs.fedoraproject.org/cgit/grub2.git/tree/0460-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch?h=f20)
|
||||
@ -91,10 +91,14 @@ hierarchy for managing purposes as `/sys/fs/cgroup/systemd/`.
|
||||
|
||||
3. **Hybrid** — this is a hybrid between the unified and legacy mode. It's set
|
||||
up mostly like legacy, except that there's also an additional hierarchy
|
||||
`/sys/fs/cgroup/unified/` that contains the cgroupsv2 hierarchy. In this mode
|
||||
compatibility with cgroupsv1 is retained while some cgroupsv2 features are
|
||||
available too. This mode is a stopgap. Don't bother with this too much unless
|
||||
you have too much free time.
|
||||
`/sys/fs/cgroup/unified/` that contains the cgroupsv2 hierarchy. (Note that in
|
||||
this mode the unified hierarchy won't have controllers attached, the
|
||||
controllers are all mounted as separate hierarchies as in legacy mode,
|
||||
i.e. `/sys/fs/cgroup/unified/` is purely and exclusively about core cgroupsv2
|
||||
functionality and not about resource management.) In this mode compatibility
|
||||
with cgroupsv1 is retained while some cgroupsv2 features are available
|
||||
too. This mode is a stopgap. Don't bother with this too much unless you have
|
||||
too much free time.
|
||||
|
||||
To say this clearly, legacy and hybrid modes have no future. If you develop
|
||||
software today and don't focus on the unified mode, then you are writing
|
||||
@ -118,7 +122,7 @@ thinking about them as orthogonal won't help you in the long run anyway.
|
||||
If you wonder how to detect which of these three modes is currently used, use
|
||||
`statfs()` on `/sys/fs/cgroup/`. If it reports `CGROUP2_SUPER_MAGIC` in its
|
||||
`.f_type` field, then you are in unified mode. If it reports `TMPFS_MAGIC` then
|
||||
you are either in legacy or hybrid mode. To distuingish these two cases, run
|
||||
you are either in legacy or hybrid mode. To distinguish these two cases, run
|
||||
`statfs()` again on `/sys/fs/cgroup/unified/`. If that succeeds and reports
|
||||
`CGROUP2_SUPER_MAGIC` you are in hybrid mode, otherwise not.
|
||||
|
||||
@ -240,6 +244,19 @@ So, if you want to do your own raw cgroups kernel level access, then allocate a
|
||||
scope unit, or a service unit (or just use the service unit you already have
|
||||
for your service code), and turn on delegation for it.
|
||||
|
||||
(OK, here's one caveat: if you turn on delegation for a service, and that
|
||||
service has `ExecStartPost=`, `ExecReload=`, `ExecStop=` or `ExecStopPost=`
|
||||
set, then these commands will be executed within the `.control/` sub-cgroup of
|
||||
your service's cgroup. This is necessary because by turning on delegation we
|
||||
have to assume that the cgroup delegated to your service is now an *inner*
|
||||
cgroup, which means that it may not directly contain any processes. Hence, if
|
||||
your service has any of these four settings set, you must be prepared that a
|
||||
`.control/` subcgroup might appear, managed by the service manager. This also
|
||||
means that your service code should have moved itself further down the cgroup
|
||||
tree by the time it notifies the service manager about start-up readiness, so
|
||||
that the service's main cgroup is definitely an inner node by the time the
|
||||
service manager might start `ExecStartPost=`.)
|
||||
|
||||
## Three Scenarios
|
||||
|
||||
Let's say you write a container manager, and you wonder what to do regarding
|
||||
1
docs/CNAME
Normal file
1
docs/CNAME
Normal file
@ -0,0 +1 @@
|
||||
systemd.io
|
||||
14
docs/CODE_OF_CONDUCT.md
Normal file
14
docs/CODE_OF_CONDUCT.md
Normal file
@ -0,0 +1,14 @@
|
||||
# The systemd Community Conduct Guidelines
|
||||
|
||||
This document provides community guidelines for a safe, respectful, productive, and collaborative place for any person who is willing to contribute to systemd. It applies to all “collaborative spaces”, which is defined as community communications channels (such as mailing lists, submitted patches, commit comments, etc.).
|
||||
|
||||
- Participants will be tolerant of opposing views.
|
||||
- Participants must ensure that their language and actions are free of personal attacks and disparaging personal remarks.
|
||||
- When interpreting the words and actions of others, participants should always assume good intentions.
|
||||
- Behaviour which can be reasonably considered harassment will not be tolerated.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at systemd-conduct@googlegroups.com. This team currently consists of David Strauss <<systemd-conduct@davidstrauss.net>>, Ekaterina Gerasimova (Kat) <<Kittykat3756@gmail.com>>, and Zbigniew Jędrzejewski-Szmek <<zbyszek@in.waw.pl>>. In the unfortunate event that you wish to make a complaint against one of the members, you may instead contact any of the other members individually.
|
||||
|
||||
All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
|
||||
@ -56,5 +56,9 @@ available functionality:
|
||||
13. When building systemd from a git checkout the build scripts will
|
||||
automatically enable a git commit hook that ensures whitespace cleanliness.
|
||||
|
||||
Access to Coverity and oss-fuzz reports is limited. Please reach out the the
|
||||
maintainers is you need access.
|
||||
14. [LGTM](https://lgtm.com/) analyzes every commit pushed to master. The list
|
||||
of active alerts can be found
|
||||
[here](https://lgtm.com/projects/g/systemd/systemd/alerts/?mode=list).
|
||||
|
||||
Access to Coverity and oss-fuzz reports is limited. Please reach out to the
|
||||
maintainers if you need access.
|
||||
520
docs/CODING_STYLE.md
Normal file
520
docs/CODING_STYLE.md
Normal file
@ -0,0 +1,520 @@
|
||||
# Coding Style
|
||||
|
||||
- 8ch indent, no tabs, except for files in `man/` which are 2ch indent,
|
||||
and still no tabs.
|
||||
|
||||
- We prefer `/* comments */` over `// comments` in code you commit, please. This
|
||||
way `// comments` are left for developers to use for local, temporary
|
||||
commenting of code for debug purposes (i.e. uncommittable stuff), making such
|
||||
comments easily discernible from explanatory, documenting code comments
|
||||
(i.e. committable stuff).
|
||||
|
||||
- Don't break code lines too eagerly. We do **not** force line breaks at 80ch,
|
||||
all of today's screens should be much larger than that. But then again, don't
|
||||
overdo it, ~109ch should be enough really. The `.editorconfig`, `.vimrc` and
|
||||
`.dir-locals.el` files contained in the repository will set this limit up for
|
||||
you automatically, if you let them (as well as a few other things).
|
||||
|
||||
- Variables and functions **must** be static, unless they have a
|
||||
prototype, and are supposed to be exported.
|
||||
|
||||
- structs in `PascalCase` (with exceptions, such as public API structs),
|
||||
variables and functions in `snake_case`.
|
||||
|
||||
- The destructors always deregister the object from the next bigger
|
||||
object, not the other way around.
|
||||
|
||||
- To minimize strict aliasing violations, we prefer unions over casting.
|
||||
|
||||
- For robustness reasons, destructors should be able to destruct
|
||||
half-initialized objects, too.
|
||||
|
||||
- Error codes are returned as negative `Exxx`. e.g. `return -EINVAL`. There
|
||||
are some exceptions: for constructors, it is OK to return `NULL` on
|
||||
OOM. For lookup functions, `NULL` is fine too for "not found".
|
||||
|
||||
Be strict with this. When you write a function that can fail due to
|
||||
more than one cause, it *really* should have an `int` as the return value
|
||||
for the error code.
|
||||
|
||||
- Do not bother with error checking whether writing to stdout/stderr
|
||||
worked.
|
||||
|
||||
- Do not log errors from "library" code, only do so from "main
|
||||
program" code. (With one exception: it is OK to log with DEBUG level
|
||||
from any code, with the exception of maybe inner loops).
|
||||
|
||||
- Always check OOM. There is no excuse. In program code, you can use
|
||||
`log_oom()` for then printing a short message, but not in "library" code.
|
||||
|
||||
- Do not issue NSS requests (that includes user name and host name
|
||||
lookups) from PID 1 as this might trigger deadlocks when those
|
||||
lookups involve synchronously talking to services that we would need
|
||||
to start up.
|
||||
|
||||
- Do not synchronously talk to any other service from PID 1, due to
|
||||
risk of deadlocks.
|
||||
|
||||
- Avoid fixed-size string buffers, unless you really know the maximum
|
||||
size and that maximum size is small. They are a source of errors,
|
||||
since they possibly result in truncated strings. It is often nicer
|
||||
to use dynamic memory, `alloca()` or VLAs. If you do allocate fixed-size
|
||||
strings on the stack, then it is probably only OK if you either
|
||||
use a maximum size such as `LINE_MAX`, or count in detail the maximum
|
||||
size a string can have. (`DECIMAL_STR_MAX` and `DECIMAL_STR_WIDTH`
|
||||
macros are your friends for this!)
|
||||
|
||||
Or in other words, if you use `char buf[256]` then you are likely
|
||||
doing something wrong!
|
||||
|
||||
- Stay uniform. For example, always use `usec_t` for time
|
||||
values. Do not mix `usec` and `msec`, and `usec` and whatnot.
|
||||
|
||||
- Make use of `_cleanup_free_` and friends. It makes your code much
|
||||
nicer to read (and shorter)!
|
||||
|
||||
- Be exceptionally careful when formatting and parsing floating point
|
||||
numbers. Their syntax is locale dependent (i.e. `5.000` in en_US is
|
||||
generally understood as 5, while in de_DE as 5000.).
|
||||
|
||||
- Try to use this:
|
||||
|
||||
```c
|
||||
void foo() {
|
||||
}
|
||||
```
|
||||
|
||||
instead of this:
|
||||
|
||||
```c
|
||||
void foo()
|
||||
{
|
||||
}
|
||||
```
|
||||
|
||||
But it is OK if you do not.
|
||||
|
||||
- Single-line `if` blocks should not be enclosed in `{}`. Use this:
|
||||
|
||||
```c
|
||||
if (foobar)
|
||||
waldo();
|
||||
```
|
||||
|
||||
instead of this:
|
||||
|
||||
```c
|
||||
if (foobar) {
|
||||
waldo();
|
||||
}
|
||||
```
|
||||
|
||||
- Do not write `foo ()`, write `foo()`.
|
||||
|
||||
- Please use `streq()` and `strneq()` instead of `strcmp()`, `strncmp()` where
|
||||
applicable (i.e. wherever you just care about equality/inequality, not about
|
||||
the sorting order).
|
||||
|
||||
- Preferably allocate stack variables on the top of the block:
|
||||
|
||||
```c
|
||||
{
|
||||
int a, b;
|
||||
|
||||
a = 5;
|
||||
b = a;
|
||||
}
|
||||
```
|
||||
|
||||
- Unless you allocate an array, `double` is always the better choice
|
||||
than `float`. Processors speak `double` natively anyway, so this is
|
||||
no speed benefit, and on calls like `printf()` `float`s get promoted
|
||||
to `double`s anyway, so there is no point.
|
||||
|
||||
- Do not mix function invocations with variable definitions in one
|
||||
line. Wrong:
|
||||
|
||||
```c
|
||||
{
|
||||
int a = foobar();
|
||||
uint64_t x = 7;
|
||||
}
|
||||
```
|
||||
|
||||
Right:
|
||||
|
||||
```c
|
||||
{
|
||||
int a;
|
||||
uint64_t x = 7;
|
||||
|
||||
a = foobar();
|
||||
}
|
||||
```
|
||||
|
||||
- Use `goto` for cleaning up, and only use it for that. i.e. you may
|
||||
only jump to the end of a function, and little else. Never jump
|
||||
backwards!
|
||||
|
||||
- Think about the types you use. If a value cannot sensibly be
|
||||
negative, do not use `int`, but use `unsigned`.
|
||||
|
||||
- Use `char` only for actual characters. Use `uint8_t` or `int8_t`
|
||||
when you actually mean a byte-sized signed or unsigned
|
||||
integers. When referring to a generic byte, we generally prefer the
|
||||
unsigned variant `uint8_t`. Do not use types based on `short`. They
|
||||
*never* make sense. Use `int`, `long`, `long long`, all in
|
||||
unsigned and signed fashion, and the fixed-size types
|
||||
`uint8_t`, `uint16_t`, `uint32_t`, `uint64_t`, `int8_t`, `int16_t`, `int32_t` and so on,
|
||||
as well as `size_t`, but nothing else. Do not use kernel types like
|
||||
`u32` and so on, leave that to the kernel.
|
||||
|
||||
- Public API calls (i.e. functions exported by our shared libraries)
|
||||
must be marked `_public_` and need to be prefixed with `sd_`. No
|
||||
other functions should be prefixed like that.
|
||||
|
||||
- In public API calls, you **must** validate all your input arguments for
|
||||
programming error with `assert_return()` and return a sensible return
|
||||
code. In all other calls, it is recommended to check for programming
|
||||
errors with a more brutal `assert()`. We are more forgiving to public
|
||||
users than for ourselves! Note that `assert()` and `assert_return()`
|
||||
really only should be used for detecting programming errors, not for
|
||||
runtime errors. `assert()` and `assert_return()` by usage of `_likely_()`
|
||||
inform the compiler that he should not expect these checks to fail,
|
||||
and they inform fellow programmers about the expected validity and
|
||||
range of parameters.
|
||||
|
||||
- Never use `strtol()`, `atoi()` and similar calls. Use `safe_atoli()`,
|
||||
`safe_atou32()` and suchlike instead. They are much nicer to use in
|
||||
most cases and correctly check for parsing errors.
|
||||
|
||||
- For every function you add, think about whether it is a "logging"
|
||||
function or a "non-logging" function. "Logging" functions do logging
|
||||
on their own, "non-logging" function never log on their own and
|
||||
expect their callers to log. All functions in "library" code,
|
||||
i.e. in `src/shared/` and suchlike must be "non-logging". Every time a
|
||||
"logging" function calls a "non-logging" function, it should log
|
||||
about the resulting errors. If a "logging" function calls another
|
||||
"logging" function, then it should not generate log messages, so
|
||||
that log messages are not generated twice for the same errors.
|
||||
|
||||
- If possible, do a combined log & return operation:
|
||||
|
||||
```c
|
||||
r = operation(...);
|
||||
if (r < 0)
|
||||
return log_(error|warning|notice|...)_errno(r, "Failed to ...: %m");
|
||||
```
|
||||
|
||||
If the error value is "synthetic", i.e. it was not received from
|
||||
the called function, use `SYNTHETIC_ERRNO` wrapper to tell the logging
|
||||
system to not log the errno value, but still return it:
|
||||
|
||||
```c
|
||||
n = read(..., s, sizeof s);
|
||||
if (n != sizeof s)
|
||||
return log_error_errno(SYNTHETIC_ERRNO(EIO), "Failed to read ...");
|
||||
```
|
||||
|
||||
- Avoid static variables, except for caches and very few other
|
||||
cases. Think about thread-safety! While most of our code is never
|
||||
used in threaded environments, at least the library code should make
|
||||
sure it works correctly in them. Instead of doing a lot of locking
|
||||
for that, we tend to prefer using TLS to do per-thread caching (which
|
||||
only works for small, fixed-size cache objects), or we disable
|
||||
caching for any thread that is not the main thread. Use
|
||||
`is_main_thread()` to detect whether the calling thread is the main
|
||||
thread.
|
||||
|
||||
- Command line option parsing:
|
||||
- Do not print full `help()` on error, be specific about the error.
|
||||
- Do not print messages to stdout on error.
|
||||
- Do not POSIX_ME_HARDER unless necessary, i.e. avoid `+` in option string.
|
||||
|
||||
- Do not write functions that clobber call-by-reference variables on
|
||||
failure. Use temporary variables for these cases and change the
|
||||
passed in variables only on success.
|
||||
|
||||
- When you allocate a file descriptor, it should be made `O_CLOEXEC`
|
||||
right from the beginning, as none of our files should leak to forked
|
||||
binaries by default. Hence, whenever you open a file, `O_CLOEXEC` must
|
||||
be specified, right from the beginning. This also applies to
|
||||
sockets. Effectively, this means that all invocations to:
|
||||
|
||||
- `open()` must get `O_CLOEXEC` passed,
|
||||
- `socket()` and `socketpair()` must get `SOCK_CLOEXEC` passed,
|
||||
- `recvmsg()` must get `MSG_CMSG_CLOEXEC` set,
|
||||
- `F_DUPFD_CLOEXEC` should be used instead of `F_DUPFD`, and so on,
|
||||
- invocations of `fopen()` should take `e`.
|
||||
|
||||
- We never use the POSIX version of `basename()` (which glibc defines it in
|
||||
`libgen.h`), only the GNU version (which glibc defines in `string.h`).
|
||||
The only reason to include `libgen.h` is because `dirname()`
|
||||
is needed. Every time you need that please immediately undefine
|
||||
`basename()`, and add a comment about it, so that no code ever ends up
|
||||
using the POSIX version!
|
||||
|
||||
- Use the bool type for booleans, not integers. One exception: in public
|
||||
headers (i.e those in `src/systemd/sd-*.h`) use integers after all, as `bool`
|
||||
is C99 and in our public APIs we try to stick to C89 (with a few extension).
|
||||
|
||||
- When you invoke certain calls like `unlink()`, or `mkdir_p()` and you
|
||||
know it is safe to ignore the error it might return (because a later
|
||||
call would detect the failure anyway, or because the error is in an
|
||||
error path and you thus couldn't do anything about it anyway), then
|
||||
make this clear by casting the invocation explicitly to `(void)`. Code
|
||||
checks like Coverity understand that, and will not complain about
|
||||
ignored error codes. Hence, please use this:
|
||||
|
||||
```c
|
||||
(void) unlink("/foo/bar/baz");
|
||||
```
|
||||
|
||||
instead of just this:
|
||||
|
||||
```c
|
||||
unlink("/foo/bar/baz");
|
||||
```
|
||||
|
||||
Don't cast function calls to `(void)` that return no error
|
||||
conditions. Specifically, the various `xyz_unref()` calls that return a `NULL`
|
||||
object shouldn't be cast to `(void)`, since not using the return value does not
|
||||
hide any errors.
|
||||
|
||||
- Don't invoke `exit()`, ever. It is not replacement for proper error
|
||||
handling. Please escalate errors up your call chain, and use normal
|
||||
`return` to exit from the main function of a process. If you
|
||||
`fork()`ed off a child process, please use `_exit()` instead of `exit()`,
|
||||
so that the exit handlers are not run.
|
||||
|
||||
- Please never use `dup()`. Use `fcntl(fd, F_DUPFD_CLOEXEC, 3)`
|
||||
instead. For two reason: first, you want `O_CLOEXEC` set on the new `fd`
|
||||
(see above). Second, `dup()` will happily duplicate your `fd` as 0, 1,
|
||||
2, i.e. stdin, stdout, stderr, should those `fd`s be closed. Given the
|
||||
special semantics of those `fd`s, it's probably a good idea to avoid
|
||||
them. `F_DUPFD_CLOEXEC` with `3` as parameter avoids them.
|
||||
|
||||
- When you define a destructor or `unref()` call for an object, please
|
||||
accept a `NULL` object and simply treat this as NOP. This is similar
|
||||
to how libc `free()` works, which accepts `NULL` pointers and becomes a
|
||||
NOP for them. By following this scheme a lot of `if` checks can be
|
||||
removed before invoking your destructor, which makes the code
|
||||
substantially more readable and robust.
|
||||
|
||||
- Related to this: when you define a destructor or `unref()` call for an
|
||||
object, please make it return the same type it takes and always
|
||||
return `NULL` from it. This allows writing code like this:
|
||||
|
||||
```c
|
||||
p = foobar_unref(p);
|
||||
```
|
||||
|
||||
which will always work regardless if `p` is initialized or not, and
|
||||
guarantees that `p` is `NULL` afterwards, all in just one line.
|
||||
|
||||
- Use `alloca()`, but never forget that it is not OK to invoke `alloca()`
|
||||
within a loop or within function call parameters. `alloca()` memory is
|
||||
released at the end of a function, and not at the end of a `{}`
|
||||
block. Thus, if you invoke it in a loop, you keep increasing the
|
||||
stack pointer without ever releasing memory again. (VLAs have better
|
||||
behavior in this case, so consider using them as an alternative.)
|
||||
Regarding not using `alloca()` within function parameters, see the
|
||||
BUGS section of the `alloca(3)` man page.
|
||||
|
||||
- Use `memzero()` or even better `zero()` instead of `memset(..., 0, ...)`
|
||||
|
||||
- Instead of using `memzero()`/`memset()` to initialize structs allocated
|
||||
on the stack, please try to use c99 structure initializers. It's
|
||||
short, prettier and actually even faster at execution. Hence:
|
||||
|
||||
```c
|
||||
struct foobar t = {
|
||||
.foo = 7,
|
||||
.bar = "bazz",
|
||||
};
|
||||
```
|
||||
|
||||
instead of:
|
||||
|
||||
```c
|
||||
struct foobar t;
|
||||
zero(t);
|
||||
t.foo = 7;
|
||||
t.bar = "bazz";
|
||||
```
|
||||
|
||||
- When returning a return code from `main()`, please preferably use
|
||||
`EXIT_FAILURE` and `EXIT_SUCCESS` as defined by libc.
|
||||
|
||||
- The order in which header files are included doesn't matter too
|
||||
much. systemd-internal headers must not rely on an include order, so
|
||||
it is safe to include them in any order possible.
|
||||
However, to not clutter global includes, and to make sure internal
|
||||
definitions will not affect global headers, please always include the
|
||||
headers of external components first (these are all headers enclosed
|
||||
in <>), followed by our own exported headers (usually everything
|
||||
that's prefixed by `sd-`), and then followed by internal headers.
|
||||
Furthermore, in all three groups, order all includes alphabetically
|
||||
so duplicate includes can easily be detected.
|
||||
|
||||
- To implement an endless loop, use `for (;;)` rather than `while (1)`.
|
||||
The latter is a bit ugly anyway, since you probably really
|
||||
meant `while (true)`. To avoid the discussion what the right
|
||||
always-true expression for an infinite while loop is, our
|
||||
recommendation is to simply write it without any such expression by
|
||||
using `for (;;)`.
|
||||
|
||||
- Never use the `off_t` type, and particularly avoid it in public
|
||||
APIs. It's really weirdly defined, as it usually is 64-bit and we
|
||||
don't support it any other way, but it could in theory also be
|
||||
32-bit. Which one it is depends on a compiler switch chosen by the
|
||||
compiled program, which hence corrupts APIs using it unless they can
|
||||
also follow the program's choice. Moreover, in systemd we should
|
||||
parse values the same way on all architectures and cannot expose
|
||||
`off_t` values over D-Bus. To avoid any confusion regarding conversion
|
||||
and ABIs, always use simply `uint64_t` directly.
|
||||
|
||||
- Commit message subject lines should be prefixed with an appropriate
|
||||
component name of some kind. For example "journal: ", "nspawn: " and
|
||||
so on.
|
||||
|
||||
- Do not use "Signed-Off-By:" in your commit messages. That's a kernel
|
||||
thing we don't do in the systemd project.
|
||||
|
||||
- Avoid leaving long-running child processes around, i.e. `fork()`s that
|
||||
are not followed quickly by an `execv()` in the child. Resource
|
||||
management is unclear in this case, and memory CoW will result in
|
||||
unexpected penalties in the parent much, much later on.
|
||||
|
||||
- Don't block execution for arbitrary amounts of time using `usleep()`
|
||||
or a similar call, unless you really know what you do. Just "giving
|
||||
something some time", or so is a lazy excuse. Always wait for the
|
||||
proper event, instead of doing time-based poll loops.
|
||||
|
||||
- To determine the length of a constant string `"foo"`, don't bother with
|
||||
`sizeof("foo")-1`, please use `strlen()` instead (both gcc and clang optimize
|
||||
the call away for fixed strings). The only exception is when declaring an
|
||||
array. In that case use STRLEN, which evaluates to a static constant and
|
||||
doesn't force the compiler to create a VLA.
|
||||
|
||||
- If you want to concatenate two or more strings, consider using `strjoina()`
|
||||
or `strjoin()` rather than `asprintf()`, as the latter is a lot slower. This
|
||||
matters particularly in inner loops (but note that `strjoina()` cannot be
|
||||
used there).
|
||||
|
||||
- Please avoid using global variables as much as you can. And if you
|
||||
do use them make sure they are static at least, instead of
|
||||
exported. Especially in library-like code it is important to avoid
|
||||
global variables. Why are global variables bad? They usually hinder
|
||||
generic reusability of code (since they break in threaded programs,
|
||||
and usually would require locking there), and as the code using them
|
||||
has side-effects make programs non-transparent. That said, there are
|
||||
many cases where they explicitly make a lot of sense, and are OK to
|
||||
use. For example, the log level and target in `log.c` is stored in a
|
||||
global variable, and that's OK and probably expected by most. Also
|
||||
in many cases we cache data in global variables. If you add more
|
||||
caches like this, please be careful however, and think about
|
||||
threading. Only use static variables if you are sure that
|
||||
thread-safety doesn't matter in your case. Alternatively, consider
|
||||
using TLS, which is pretty easy to use with gcc's `thread_local`
|
||||
concept. It's also OK to store data that is inherently global in
|
||||
global variables, for example data parsed from command lines, see
|
||||
below.
|
||||
|
||||
- If you parse a command line, and want to store the parsed parameters
|
||||
in global variables, please consider prefixing their names with
|
||||
`arg_`. We have been following this naming rule in most of our
|
||||
tools, and we should continue to do so, as it makes it easy to
|
||||
identify command line parameter variables, and makes it clear why it
|
||||
is OK that they are global variables.
|
||||
|
||||
- When exposing public C APIs, be careful what function parameters you make
|
||||
`const`. For example, a parameter taking a context object should probably not
|
||||
be `const`, even if you are writing an otherwise read-only accessor function
|
||||
for it. The reason is that making it `const` fixates the contract that your
|
||||
call won't alter the object ever, as part of the API. However, that's often
|
||||
quite a promise, given that this even prohibits object-internal caching or
|
||||
lazy initialization of object variables. Moreover, it's usually not too useful
|
||||
for client applications. Hence, please be careful and avoid `const` on object
|
||||
parameters, unless you are very sure `const` is appropriate.
|
||||
|
||||
- Make sure to enforce limits on every user controllable resource. If the user
|
||||
can allocate resources in your code, your code must enforce some form of
|
||||
limits after which it will refuse operation. It's fine if it is hard-coded (at
|
||||
least initially), but it needs to be there. This is particularly important
|
||||
for objects that unprivileged users may allocate, but also matters for
|
||||
everything else any user may allocated.
|
||||
|
||||
- `htonl()`/`ntohl()` and `htons()`/`ntohs()` are weird. Please use `htobe32()` and
|
||||
`htobe16()` instead, it's much more descriptive, and actually says what really
|
||||
is happening, after all `htonl()` and `htons()` don't operate on `long`s and
|
||||
`short`s as their name would suggest, but on `uint32_t` and `uint16_t`. Also,
|
||||
"network byte order" is just a weird name for "big endian", hence we might
|
||||
want to call it "big endian" right-away.
|
||||
|
||||
- You might wonder what kind of common code belongs in `src/shared/` and what
|
||||
belongs in `src/basic/`. The split is like this: anything that is used to
|
||||
implement the public shared object we provide (sd-bus, sd-login, sd-id128,
|
||||
nss-systemd, nss-mymachines, nss-resolve, nss-myhostname, pam_systemd), must
|
||||
be located in `src/basic` (those objects are not allowed to link to
|
||||
libsystemd-shared.so). Conversely, anything which is shared between multiple
|
||||
components and does not need to be in `src/basic/`, should be in
|
||||
`src/shared/`.
|
||||
|
||||
To summarize:
|
||||
|
||||
`src/basic/`
|
||||
- may be used by all code in the tree
|
||||
- may not use any code outside of `src/basic/`
|
||||
|
||||
`src/libsystemd/`
|
||||
- may be used by all code in the tree, except for code in `src/basic/`
|
||||
- may not use any code outside of `src/basic/`, `src/libsystemd/`
|
||||
|
||||
`src/shared/`
|
||||
- may be used by all code in the tree, except for code in `src/basic/`,
|
||||
`src/libsystemd/`, `src/nss-*`, `src/login/pam_systemd.*`, and files under
|
||||
`src/journal/` that end up in `libjournal-client.a` convenience library.
|
||||
- may not use any code outside of `src/basic/`, `src/libsystemd/`, `src/shared/`
|
||||
|
||||
- Our focus is on the GNU libc (glibc), not any other libcs. If other libcs are
|
||||
incompatible with glibc it's on them. However, if there are equivalent POSIX
|
||||
and Linux/GNU-specific APIs, we generally prefer the POSIX APIs. If there
|
||||
aren't, we are happy to use GNU or Linux APIs, and expect non-GNU
|
||||
implementations of libc to catch up with glibc.
|
||||
|
||||
- Whenever installing a signal handler, make sure to set `SA_RESTART` for it, so
|
||||
that interrupted system calls are automatically restarted, and we minimize
|
||||
hassles with handling `EINTR` (in particular as `EINTR` handling is pretty broken
|
||||
on Linux).
|
||||
|
||||
- When applying C-style unescaping as well as specifier expansion on the same
|
||||
string, always apply the C-style unescaping fist, followed by the specifier
|
||||
expansion. When doing the reverse, make sure to escape `%` in specifier-style
|
||||
first (i.e. `%` → `%%`), and then do C-style escaping where necessary.
|
||||
|
||||
- It's a good idea to use `O_NONBLOCK` when opening 'foreign' regular files, i.e.
|
||||
file system objects that are supposed to be regular files whose paths where
|
||||
specified by the user and hence might actually refer to other types of file
|
||||
system objects. This is a good idea so that we don't end up blocking on
|
||||
'strange' file nodes, for example if the user pointed us to a FIFO or device
|
||||
node which may block when opening. Moreover even for actual regular files
|
||||
`O_NONBLOCK` has a benefit: it bypasses any mandatory lock that might be in
|
||||
effect on the regular file. If in doubt consider turning off `O_NONBLOCK` again
|
||||
after opening.
|
||||
|
||||
- When referring to a configuration file option in the documentation and such,
|
||||
please always suffix it with `=`, to indicate that it is a configuration file
|
||||
setting.
|
||||
|
||||
- When referring to a command line option in the documentation and such, please
|
||||
always prefix with `--` or `-` (as appropriate), to indicate that it is a
|
||||
command line option.
|
||||
|
||||
- When referring to a file system path that is a directory, please always
|
||||
suffix it with `/`, to indicate that it is a directory, not a regular file
|
||||
(or other file system object).
|
||||
|
||||
- Don't use `fgets()`, it's too hard to properly handle errors such as overly
|
||||
long lines. Use `read_line()` instead, which is our own function that handles
|
||||
this much nicer.
|
||||
@ -24,8 +24,8 @@ If you discover a security vulnerability, we'd appreciate a non-public disclosur
|
||||
## Posting Pull Requests
|
||||
|
||||
* Make sure to post PRs only relative to a very recent git master.
|
||||
* Follow our [Coding Style](https://raw.githubusercontent.com/systemd/systemd/master/doc/CODING_STYLE) when contributing code. This is a requirement for all code we merge.
|
||||
* Please make sure to test your change before submitting the PR. See [HACKING](https://raw.githubusercontent.com/systemd/systemd/master/doc/HACKING) for details how to do this.
|
||||
* Follow our [Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.
|
||||
* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING.md) for details on how to do this.
|
||||
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR, if the build and tests don't pass.
|
||||
* If you need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions.
|
||||
* After you have pushed a new version, add a comment about the new version (no notification is sent just for the commits, so it's easy to miss the update without an explicit comment). If you are a member of the systemd project on GitHub, remove the `reviewed/needs-rework` label.
|
||||
75
docs/DISTRO_PORTING.md
Normal file
75
docs/DISTRO_PORTING.md
Normal file
@ -0,0 +1,75 @@
|
||||
# Porting systemd To New Distributions
|
||||
|
||||
## HOWTO
|
||||
|
||||
You need to make the follow changes to adapt systemd to your
|
||||
distribution:
|
||||
|
||||
1. Find the right configure parameters for:
|
||||
|
||||
* `-Drootprefix=`
|
||||
* `-Dsysvinit-path=`
|
||||
* `-Dsysvrcnd-path=`
|
||||
* `-Drc-local=`
|
||||
* `-Dhalt-local=`
|
||||
* `-Dloadkeys-path=`
|
||||
* `-Dsetfont-path=`
|
||||
* `-Dtty-gid=`
|
||||
* `-Dntp-servers=`
|
||||
* `-Ddns-servers=`
|
||||
* `-Dsupport-url=`
|
||||
|
||||
2. Try it out.
|
||||
|
||||
Play around (as an ordinary user) with
|
||||
`/usr/lib/systemd/systemd --test --system` for a test run
|
||||
of systemd without booting. This will read the unit files and
|
||||
print the initial transaction it would execute during boot-up.
|
||||
This will also inform you about ordering loops and suchlike.
|
||||
|
||||
## NTP Pool
|
||||
|
||||
By default, systemd-timesyncd uses the Google Public NTP servers
|
||||
`time[1-4].google.com`, if no other NTP configuration is available.
|
||||
They serve time that uses a
|
||||
[leap second smear](https://developers.google.com/time/smear)
|
||||
and can be up to .5s off from servers that use stepped leap seconds.
|
||||
|
||||
If you prefer to use leap second steps, please register your own
|
||||
vendor pool at ntp.org and make it the built-in default by
|
||||
passing `-Dntp-servers=` to meson. Registering vendor
|
||||
pools is [free](http://www.pool.ntp.org/en/vendors.html).
|
||||
|
||||
Use `-Dntp-servers=` to direct systemd-timesyncd to different fallback
|
||||
NTP servers.
|
||||
|
||||
## DNS Servers
|
||||
|
||||
By default, systemd-resolved uses the Google Public DNS servers
|
||||
`8.8.8.8`, `8.8.4.4`, `2001:4860:4860::8888`, `2001:4860:4860::8844`
|
||||
as fallback, if no other DNS configuration is available.
|
||||
|
||||
Use `-Ddns-servers=` to direct systemd-resolved to different fallback
|
||||
DNS servers.
|
||||
|
||||
## PAM
|
||||
|
||||
The default PAM config shipped by systemd is really bare bones.
|
||||
It does not include many modules your distro might want to enable
|
||||
to provide a more seamless experience. For example, limits set in
|
||||
`/etc/security/limits.conf` will not be read unless you load `pam_limits`.
|
||||
Make sure you add modules your distro expects from user services.
|
||||
|
||||
Pass `-Dpamconfdir=no` to meson to avoid installing this file and
|
||||
instead install your own.
|
||||
|
||||
## Contributing Upstream
|
||||
|
||||
We generally do no longer accept distribution-specific patches to
|
||||
systemd upstream. If you have to make changes to systemd's source code
|
||||
to make it work on your distribution, unless your code is generic
|
||||
enough to be generally useful, we are unlikely to merge it. Please
|
||||
always consider adopting the upstream defaults. If that is not
|
||||
possible, please maintain the relevant patches downstream.
|
||||
|
||||
Thank you for understanding.
|
||||
@ -37,6 +37,23 @@ All tools:
|
||||
useful for debugging, in order to test generators and other code against
|
||||
specific kernel command lines.
|
||||
|
||||
* `$SYSTEMD_IN_INITRD` — takes a boolean. If set, overrides initrd detection.
|
||||
This is useful for debugging and testing initrd-only programs in the main
|
||||
system.
|
||||
|
||||
* `$SYSTEMD_BUS_TIMEOUT=SECS` — specifies the maximum time to wait for method call
|
||||
completion. If no time unit is specified, assumes seconds. The usual other units
|
||||
are understood, too (us, ms, s, min, h, d, w, month, y). If it is not set or set
|
||||
to 0, then the built-in default is used.
|
||||
|
||||
* `$SYSTEMD_MEMPOOL=0` — if set, the internal memory caching logic employed by
|
||||
hash tables is turned off, and libc malloc() is used for all allocations.
|
||||
|
||||
* `$SYSTEMD_EMOJI=0` — if set, tools such as "systemd-analyze security" will
|
||||
not output graphical smiley emojis, but ASCII alternatives instead. Note that
|
||||
this only controls use of Unicode emoji glyphs, and has no effect on other
|
||||
Unicode glyphs.
|
||||
|
||||
systemctl:
|
||||
|
||||
* `$SYSTEMCTL_FORCE_BUS=1` — if set, do not connect to PID1's private D-Bus
|
||||
@ -65,12 +82,27 @@ systemd-nspawn:
|
||||
|
||||
* `$SYSTEMD_NSPAWN_LOCK=0` — if set, do not lock container images when running.
|
||||
|
||||
* `$SYSTEMD_NSPAWN_TMPFS_TMP=0` — if set, do not overmount /tmp in the
|
||||
container with a tmpfs, but leave the directory from the image in place.
|
||||
|
||||
systemd-logind:
|
||||
|
||||
* `$SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1` — if set, report that
|
||||
hibernation is available even if the swap devices do not provide enough room
|
||||
for it.
|
||||
|
||||
systemd-udevd:
|
||||
|
||||
* `$NET_NAMING_SCHEME=` – if set, takes a network naming scheme (i.e. one of
|
||||
"v238", "v239", "v240"…, or the special value "latest") as parameter. If
|
||||
specified udev's net_id builtin will follow the specified naming scheme when
|
||||
determining stable network interface names. This may be used to revert to
|
||||
naming schemes of older udev versions, in order to provide more stable naming
|
||||
across updates. This environment variable takes precedence over the kernel
|
||||
command line option `net.naming-scheme=`, except if the value is prefixed
|
||||
with `:` in which case the kernel command line option takes precedence, if it
|
||||
is specified as well.
|
||||
|
||||
installed systemd tests:
|
||||
|
||||
* `$SYSTEMD_TEST_DATA` — override the location of test data. This is useful if
|
||||
@ -96,3 +128,48 @@ systemd-timedated:
|
||||
NTP client services. If set, `timedatectl set-ntp on` enables and starts the
|
||||
first existing unit listed in the environment variable, and
|
||||
`timedatectl set-ntp off` disables and stops all listed units.
|
||||
|
||||
systemd-sulogin-shell:
|
||||
|
||||
* `$SYSTEMD_SULOGIN_FORCE=1` — This skips asking for the root password if the
|
||||
root password is not available (such as when the root account is locked).
|
||||
See `sulogin(8)` for more details.
|
||||
|
||||
bootctl and other tools that access the EFI System Partition (ESP):
|
||||
|
||||
* `$SYSTEMD_RELAX_ESP_CHECKS=1` — if set, the ESP validation checks are
|
||||
relaxed. Specifically, validation checks that ensure the specified ESP path
|
||||
is a FAT file system are turned off, as are checks that the path is located
|
||||
on a GPT partition with the correct type UUID.
|
||||
|
||||
* `$SYSTEMD_ESP_PATH=…` — override the path to the EFI System Partition. This
|
||||
may be used to override ESP path auto detection, and redirect any accesses to
|
||||
the ESP to the specified directory. Not that unlike with bootctl's --path=
|
||||
switch only very superficial validation of the specified path is done when
|
||||
this environment variable is used.
|
||||
|
||||
systemd itself:
|
||||
|
||||
* `$SYSTEMD_ACTIVATION_UNIT` — set for all NSS and PAM module invocations that
|
||||
are done by the service manager on behalf of a specific unit, in child
|
||||
processes that are later (after execve()) going to become unit
|
||||
processes. Contains the full unit name (e.g. "foobar.service"). NSS and PAM
|
||||
modules can use this information to determine in which context and on whose
|
||||
behalf they are being called, which may be useful to avoid deadlocks, for
|
||||
example to bypass IPC calls to the very service that is about to be
|
||||
started. Note that NSS and PAM modules should be careful to only rely on this
|
||||
data when invoked privileged, or possibly only when getppid() returns 1, as
|
||||
setting environment variables is of course possible in any even unprivileged
|
||||
contexts.
|
||||
|
||||
* `$SYSTEMD_ACTIVATION_SCOPE` — closely related to `$SYSTEMD_ACTIVATION_UNIT`,
|
||||
it is either set to `system` or `user` depending on whether the NSS/PAM
|
||||
module is called by systemd in `--system` or `--user` mode.
|
||||
|
||||
systemd-remount-fs:
|
||||
|
||||
* `$SYSTEMD_REMOUNT_ROOT_RW=1` — if set and and no entry for the root directory
|
||||
exists in /etc/fstab (this file always takes precedence), then the root
|
||||
directory is remounted writable. This is primarily used by
|
||||
systemd-gpt-auto-generator to ensure the root partition is mounted writable
|
||||
in accordance to the GPT partition flags.
|
||||
123
docs/HACKING.md
Normal file
123
docs/HACKING.md
Normal file
@ -0,0 +1,123 @@
|
||||
# Hacking on systemd
|
||||
|
||||
We welcome all contributions to systemd. If you notice a bug or a missing
|
||||
feature, please feel invited to fix it, and submit your work as a GitHub Pull
|
||||
Request (PR) at https://github.com/systemd/systemd/pull/new.
|
||||
|
||||
Please make sure to follow our [Coding Style](CODING_STYLE.md) when submitting patches.
|
||||
Also have a look at our [Contribution Guidelines](CONTRIBUTING.md).
|
||||
|
||||
When adding new functionality, tests should be added. For shared functionality
|
||||
(in `src/basic/` and `src/shared/`) unit tests should be sufficient. The general
|
||||
policy is to keep tests in matching files underneath `src/test/`,
|
||||
e.g. `src/test/test-path-util.c` contains tests for any functions in
|
||||
`src/basic/path-util.c`. If adding a new source file, consider adding a matching
|
||||
test executable. For features at a higher level, tests in `src/test/` are very
|
||||
strongly recommended. If that is not possible, integration tests in `test/` are
|
||||
encouraged.
|
||||
|
||||
Please also have a look at our list of [code quality tools](CODE_QUALITY.md) we have setup for systemd,
|
||||
to ensure our codebase stays in good shape.
|
||||
|
||||
Please always test your work before submitting a PR. For many of the components
|
||||
of systemd testing is straight-forward as you can simply compile systemd and
|
||||
run the relevant tool from the build directory.
|
||||
|
||||
For some components (most importantly, systemd/PID1 itself) this is not
|
||||
possible, however. In order to simplify testing for cases like this we provide
|
||||
a set of `mkosi` build files directly in the source tree. `mkosi` is a tool for
|
||||
building clean OS images from an upstream distribution in combination with a
|
||||
fresh build of the project in the local working directory. To make use of this,
|
||||
please acquire `mkosi` from https://github.com/systemd/mkosi first, unless your
|
||||
distribution has packaged it already and you can get it from there. After the
|
||||
tool is installed it is sufficient to type `mkosi` in the systemd project
|
||||
directory to generate a disk image `image.raw` you can boot either in
|
||||
`systemd-nspawn` or in an UEFI-capable VM:
|
||||
|
||||
```
|
||||
# systemd-nspawn -bi image.raw
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```
|
||||
# qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd -hda image.raw
|
||||
```
|
||||
|
||||
Every time you rerun the `mkosi` command a fresh image is built, incorporating
|
||||
all current changes you made to the project tree.
|
||||
|
||||
Alternatively, you may install the systemd version from your git check-out
|
||||
directly on top of your host system's directory tree. This mostly works fine,
|
||||
but of course you should know what you are doing as you might make your system
|
||||
unbootable in case of a bug in your changes. Also, you might step into your
|
||||
package manager's territory with this. Be careful!
|
||||
|
||||
And never forget: most distributions provide very simple and convenient ways to
|
||||
install all development packages necessary to build systemd. For example, on
|
||||
Fedora the following command line should be sufficient to install all of
|
||||
systemd's build dependencies:
|
||||
|
||||
```
|
||||
# dnf builddep systemd
|
||||
```
|
||||
|
||||
Putting this all together, here's a series of commands for preparing a patch
|
||||
for systemd (this example is for Fedora):
|
||||
|
||||
```sh
|
||||
$ sudo dnf builddep systemd # install build dependencies
|
||||
$ sudo dnf install mkosi # install tool to quickly build images
|
||||
$ git clone https://github.com/systemd/systemd.git
|
||||
$ cd systemd
|
||||
$ vim src/core/main.c # or wherever you'd like to make your changes
|
||||
$ meson build # configure the build
|
||||
$ ninja -C build # build it locally, see if everything compiles fine
|
||||
$ ninja -C build test # run some simple regression tests
|
||||
$ (umask 077; echo 123 > mkosi.rootpw) # set root password used by mkosi
|
||||
$ sudo mkosi # build a test image
|
||||
$ sudo systemd-nspawn -bi image.raw # boot up the test image
|
||||
$ git add -p # interactively put together your patch
|
||||
$ git commit # commit it
|
||||
$ git push REMOTE HEAD:refs/heads/BRANCH
|
||||
# where REMOTE is your "fork" on GitHub
|
||||
# and BRANCH is a branch name.
|
||||
```
|
||||
|
||||
And after that, head over to your repo on GitHub and click "Compare & pull request"
|
||||
|
||||
Happy hacking!
|
||||
|
||||
|
||||
## Fuzzers
|
||||
|
||||
systemd includes fuzzers in `src/fuzz/` that use libFuzzer and are automatically
|
||||
run by [OSS-Fuzz](https://github.com/google/oss-fuzz) with sanitizers. To add a
|
||||
fuzz target, create a new `src/fuzz/fuzz-foo.c` file with a `LLVMFuzzerTestOneInput`
|
||||
function and add it to the list in `src/fuzz/meson.build`.
|
||||
|
||||
Whenever possible, a seed corpus and a dictionary should also be added with new
|
||||
fuzz targets. The dictionary should be named `src/fuzz/fuzz-foo.dict` and the seed
|
||||
corpus should be built and exported as `$OUT/fuzz-foo_seed_corpus.zip` in
|
||||
`tools/oss-fuzz.sh`.
|
||||
|
||||
The fuzzers can be built locally if you have libFuzzer installed by running
|
||||
`tools/oss-fuzz.sh`. You should also confirm that the fuzzer runs in the
|
||||
OSS-Fuzz environment by checking out the OSS-Fuzz repo, and then running
|
||||
commands like this:
|
||||
|
||||
```
|
||||
python infra/helper.py build_image systemd
|
||||
python infra/helper.py build_fuzzers --sanitizer memory systemd ../systemd
|
||||
python infra/helper.py run_fuzzer systemd fuzz-foo
|
||||
```
|
||||
|
||||
If you find a bug that impacts the security of systemd, please follow the
|
||||
guidance in [CONTRIBUTING.md](CONTRIBUTING.md) on how to report a security vulnerability.
|
||||
|
||||
For more details on building fuzzers and integrating with OSS-Fuzz, visit:
|
||||
|
||||
- https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md
|
||||
- https://llvm.org/docs/LibFuzzer.html
|
||||
- https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md
|
||||
- https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/efficient_fuzzer.md
|
||||
@ -20,7 +20,7 @@ Portable services don't bring anything inherently new to the table. All they do
|
||||
is put together known concepts in a slightly nicer way to cover a specific set
|
||||
of use-cases in a nicer way.
|
||||
|
||||
# So, what *is* a "Portable Service"?
|
||||
## So, what *is* a "Portable Service"?
|
||||
|
||||
A portable service is ultimately just an OS tree, either inside of a directory
|
||||
tree, or inside a raw disk image containing a Linux file system. This tree is
|
||||
@ -43,7 +43,7 @@ do too.
|
||||
If you so will, "Portable Services" are a nicer way to manage chroot()
|
||||
environments, with better security, tooling and behavior.
|
||||
|
||||
# Where's the difference to a "Container"?
|
||||
## Where's the difference to a "Container"?
|
||||
|
||||
"Container" is a very vague term, after all it is used for
|
||||
systemd-nspawn/LXC-type OS containers, for Docker/rkt-like micro service
|
||||
@ -74,7 +74,7 @@ Note that portable services are only available for system services, not for
|
||||
user services. i.e. the functionality cannot be used for the stuff
|
||||
bubblewrap/flatpak is focusing on.
|
||||
|
||||
# Mode of Operation
|
||||
## Mode of Operation
|
||||
|
||||
If you have portable service image, maybe in a raw disk image called
|
||||
`foobar_0.7.23.raw`, then attaching the services to the host is as easy as:
|
||||
@ -98,16 +98,17 @@ This command does the following:
|
||||
`foobar@.{service|socket|target|timer|path}` as well as
|
||||
`foobar.*.{service|socket|target|timer|path}` and
|
||||
`foobar.{service|socket|target|timer|path}` are copied out. These unit files
|
||||
are placed in `/etc/systemd/system/` like regular unit files. Within the
|
||||
images the unit files are looked for at the usual locations, i.e. in
|
||||
`/usr/lib/systemd/system/` and `/etc/systemd/system/` and so on, relative to
|
||||
the image's root.
|
||||
are placed in `/etc/systemd/system.attached/` (which is part of the normal
|
||||
unit file search path of PID 1, and thus loaded exactly like regular unit
|
||||
files). Within the images the unit files are looked for at the usual
|
||||
locations, i.e. in `/usr/lib/systemd/system/` and `/etc/systemd/system/` and
|
||||
so on, relative to the image's root.
|
||||
|
||||
3. For each such unit file a drop-in file is created. Let's say
|
||||
`foobar-waldo.service` was one of the unit files copied to
|
||||
`/etc/systemd/system/`, then a drop-in file
|
||||
`/etc/systemd/system/foobar-waldo.service.d/20-portable.conf` is created,
|
||||
containing a few lines of additional configuration:
|
||||
`/etc/systemd/system.attached/`, then a drop-in file
|
||||
`/etc/systemd/system.attached/foobar-waldo.service.d/20-portable.conf` is
|
||||
created, containing a few lines of additional configuration:
|
||||
|
||||
```
|
||||
[Service]
|
||||
@ -140,7 +141,7 @@ Note that `portable attach` won't enable or start any of the units it copies
|
||||
out. This still has to take place in a second, separate step. (That said We
|
||||
might add options to do this automatically later on.).
|
||||
|
||||
# Requirements on Images
|
||||
## Requirements on Images
|
||||
|
||||
Note that portable services don't introduce any new image format, but most OS
|
||||
images should just work the way they are. Specifically, the following
|
||||
@ -207,14 +208,14 @@ image. To facility 3 and 4 you also need to include a boot loader in the
|
||||
image. As mentioned `mkosi -b` takes care of all of that for you, but any other
|
||||
image generator should work too.
|
||||
|
||||
# Execution Environment
|
||||
## Execution Environment
|
||||
|
||||
Note that the code in portable service images is run exactly like regular
|
||||
services. Hence there's no new execution environment to consider. Oh, unlike
|
||||
Docker would do it, as these are regular system services they aren't run as PID
|
||||
1 either, but with regular PID values.
|
||||
|
||||
# Access to host resources
|
||||
## Access to host resources
|
||||
|
||||
If services shipped with this mechanism shall be able to access host resources
|
||||
(such as files or AF_UNIX sockets for IPC), use the normal `BindPaths=` and
|
||||
@ -223,7 +224,7 @@ If services shipped with this mechanism shall be able to access host resources
|
||||
`/etc/resolv.conf`, the D-Bus system bus socket or write access to the logging
|
||||
subsystem are available to the service.
|
||||
|
||||
# Instantiation
|
||||
## Instantiation
|
||||
|
||||
Sometimes it makes sense to instantiate the same set of services multiple
|
||||
times. The portable service concept does not introduce a new logic for this. It
|
||||
@ -241,7 +242,7 @@ simple as:
|
||||
The benefit of this approach is that templating works exactly the same for
|
||||
units shipped with the OS itself as for attached portable services.
|
||||
|
||||
# Immutable images with local data
|
||||
## Immutable images with local data
|
||||
|
||||
It's a good idea to keep portable service images read-only during normal
|
||||
operation. In fact all but the `trusted` profile will default to this kind of
|
||||
64
docs/PREDICTABLE_INTERFACE_NAMES.md
Normal file
64
docs/PREDICTABLE_INTERFACE_NAMES.md
Normal file
@ -0,0 +1,64 @@
|
||||
# Predictable Network Interface Names
|
||||
|
||||
Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.
|
||||
|
||||
|
||||
## Why?
|
||||
|
||||
The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.
|
||||
|
||||
To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.
|
||||
|
||||
Another solution that has been implemented is "biosdevname" which tries to find fixed slot topology information in certain firmware interfaces and uses them to assign fixed names to interfaces which incorporate their physical location on the mainboard. In a way this naming scheme is similar to what is already done natively in udev for various device nodes via /dev/*/by-path/ symlinks. In many cases, biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes.
|
||||
|
||||
Finally, many distributions support renaming interfaces to user-chosen names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or physical locations as part of their networking scripts. This is a very good choice but does have the problem that it implies that the user is willing and capable of choosing and assigning these names.
|
||||
|
||||
We believe it is a good default choice to generalize the scheme pioneered by "biosdevname". Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place) and that broken hardware can be replaced seamlessly. That said, they admittedly are sometimes harder to read than the "eth0" or "wlan0" everybody is used to. Example: "enp5s0"
|
||||
|
||||
|
||||
## What precisely has changed in v197?
|
||||
|
||||
With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:
|
||||
|
||||
1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: `eno1`)
|
||||
1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: `ens1`)
|
||||
1. Names incorporating physical/geographical location of the connector of the hardware (example: `enp2s0`)
|
||||
1. Names incorporating the interfaces's MAC address (example: `enx78e7d1ea46da`)
|
||||
1. Classic, unpredictable kernel-native ethX naming (example: `eth0`)
|
||||
|
||||
By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.
|
||||
|
||||
This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.
|
||||
|
||||
|
||||
## Come again, what good does this do?
|
||||
|
||||
With this new scheme you now get:
|
||||
|
||||
* Stable interface names across reboots
|
||||
* Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place (to the level the firmware permits this)
|
||||
* Stable interface names when kernels or drivers are updated/changed
|
||||
* Stable interface names even if you have to replace broken ethernet cards by new ones
|
||||
* The names are automatically determined without user configuration, they just work
|
||||
* The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called
|
||||
* Fully stateless operation, changing the hardware configuration will not result in changes in /etc
|
||||
* Compatibility with read-only root
|
||||
* The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks
|
||||
* Applicability to both x86 and non-x86 machines
|
||||
* The same on all distributions that adopted systemd/udev
|
||||
* It's easy to opt out of the scheme (see below)
|
||||
|
||||
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.
|
||||
|
||||
|
||||
## I don't like this, how do I disable this?
|
||||
|
||||
You basically have three options:
|
||||
|
||||
1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: `ln -s /dev/null /etc/systemd/network/99-default.link`
|
||||
1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [[systemd.link(5)|http://www.freedesktop.org/software/systemd/man/systemd.link.html]] for more information.
|
||||
1. You pass the net.ifnames=0 on the kernel command line
|
||||
|
||||
## How does the new naming scheme look like, precisely?
|
||||
|
||||
That's documented in detail in a comment block [[the sources of the net_id built-in|https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20]]. Please refer to this in case you are wondering how to decode the new interface names.
|
||||
@ -1,4 +1,4 @@
|
||||
# Steps to a successful release
|
||||
# Steps to a Successful Release
|
||||
|
||||
1. Add all items to NEWS
|
||||
2. Update the contributors list in NEWS ("make git-contrib")
|
||||
@ -45,6 +45,8 @@ Most generic unit settings are available for transient units.
|
||||
✓ StartLimitAction=ACTION
|
||||
✓ FailureAction=
|
||||
✓ SuccessAction=
|
||||
✓ FailureActionExitStatus=
|
||||
✓ SuccessActionExitStatus=
|
||||
✓ AddRef=
|
||||
✓ RebootArgument=STRING
|
||||
✓ ConditionPathExists=
|
||||
@ -135,6 +137,8 @@ All execution-related settings are available for transient units.
|
||||
✓ SyslogLevelPrefix=
|
||||
✓ LogLevelMax=
|
||||
✓ LogExtraFields=
|
||||
✓ LogRateLimitIntervalSec=
|
||||
✓ LogRateLimitBurst=
|
||||
✓ SecureBits=
|
||||
✓ CapabilityBoundingSet=
|
||||
✓ AmbientCapabilities=
|
||||
@ -173,6 +177,7 @@ All execution-related settings are available for transient units.
|
||||
✓ TemporaryFileSystem=
|
||||
✓ PrivateTmp=
|
||||
✓ PrivateDevices=
|
||||
✓ PrivateMounts=
|
||||
✓ ProtectKernelTunables=
|
||||
✓ ProtectKernelModules=
|
||||
✓ ProtectControlGroups=
|
||||
@ -216,6 +221,7 @@ All cgroup/resource control settings are available for transient units
|
||||
✓ StartupCPUShares=
|
||||
✓ CPUQuota=
|
||||
✓ MemoryAccounting=
|
||||
✓ MemoryMin=
|
||||
✓ MemoryLow=
|
||||
✓ MemoryHigh=
|
||||
✓ MemoryMax=
|
||||
@ -254,6 +260,8 @@ All process killing settings are available for transient units:
|
||||
✓ SendSIGHUP=
|
||||
✓ KillMode=
|
||||
✓ KillSignal=
|
||||
✓ FinalKillSignal=
|
||||
✓ WatchdogSignal=
|
||||
```
|
||||
|
||||
## Service Unit Settings
|
||||
@ -276,7 +284,6 @@ Most service unit settings are available for transient units.
|
||||
✓ WatchdogSec=
|
||||
✓ Type=
|
||||
✓ Restart=
|
||||
✓ PermissionsStartOnly=
|
||||
✓ RootDirectoryStartOnly=
|
||||
✓ RemainAfterExit=
|
||||
✓ GuessMainPID=
|
||||
74
docs/TRANSLATORS.md
Normal file
74
docs/TRANSLATORS.md
Normal file
@ -0,0 +1,74 @@
|
||||
# Notes for Translators
|
||||
|
||||
systemd depends on the `gettext` package for multilingual support.
|
||||
|
||||
You'll find the i18n files in the `po/` directory.
|
||||
|
||||
The build system (meson/ninja) can be used to generate a template (`*.pot`),
|
||||
which can be used to create new translations.
|
||||
|
||||
It can also merge the template into the existing translations (`*.po`), to pick
|
||||
up new strings in need of translation.
|
||||
|
||||
Finally, it is able to compile the translations (to `*.gmo` files), so that
|
||||
they can be used by systemd software. (This step is also useful to confirm the
|
||||
syntax of the `*.po` files is correct.)
|
||||
|
||||
## Creating a New Translation
|
||||
|
||||
To create a translation to a language not yet available, start by creating the
|
||||
initial template:
|
||||
|
||||
```
|
||||
$ ninja -C build/ systemd-pot
|
||||
```
|
||||
|
||||
This will generate file `po/systemd.pot` in the source tree.
|
||||
|
||||
Then simply copy it to a new <code><i>${lang_code}</i>.po</code> file, where
|
||||
<code><i>${lang_code}</i></code> is the two-letter code for a language
|
||||
(possibly followed by a two-letter uppercase country code), according to the
|
||||
ISO 639 standard.
|
||||
|
||||
In short:
|
||||
|
||||
<pre>
|
||||
$ cp po/systemd.pot po/<i>${lang_code}</i>.po
|
||||
</pre>
|
||||
|
||||
Then edit the new <code>po/<i>${lang_code}</i>.po</code> file (for example,
|
||||
using the `poedit` GUI editor.)
|
||||
|
||||
## Updating an Existing Translation
|
||||
|
||||
Start by updating the `*.po` files from the latest template:
|
||||
|
||||
```
|
||||
$ ninja -C build/ systemd-update-po
|
||||
```
|
||||
|
||||
This will touch all the `*.po` files, so you'll want to pay attention when
|
||||
creating a git commit from this change, to only include the one translation
|
||||
you're actually updating.
|
||||
|
||||
Edit the `*.po` file, looking for empty translations and translations marked as
|
||||
"fuzzy" (which means the merger found a similar message that needs to be
|
||||
reviewed as it's expected not to match exactly.)
|
||||
|
||||
You can use any text editor to update the `*.po` files, but a good choice is
|
||||
the `poedit` editor, a graphical application specifically designed for this
|
||||
purpose.
|
||||
|
||||
Once you're done, create a git commit for the update of the `po/*.po` file you
|
||||
touched. Remember to undo the changes to the other `*.po` files (for instance,
|
||||
using `git checkout -- po/` after you commit the changes you do want to keep.)
|
||||
|
||||
# Recompiling Translations
|
||||
|
||||
You can recompile the `*.po` files using the following command:
|
||||
|
||||
```
|
||||
$ ninja -C build/ systemd-gmo
|
||||
```
|
||||
|
||||
The resulting files will be saved in the `build/po/` directory.
|
||||
@ -1,4 +1,4 @@
|
||||
# Users, Groups, UIDs and GIDs on `systemd` systems
|
||||
# Users, Groups, UIDs and GIDs on `systemd` Systems
|
||||
|
||||
Here's a summary of the requirements `systemd` (and Linux) make on UID/GID
|
||||
assignments and their ranges.
|
||||
1
docs/_config.yml
Normal file
1
docs/_config.yml
Normal file
@ -0,0 +1 @@
|
||||
theme: jekyll-theme-primer
|
||||
20
docs/index.md
Normal file
20
docs/index.md
Normal file
@ -0,0 +1,20 @@
|
||||
# systemd Documentation
|
||||
|
||||
* [Automatic Boot Assessment](https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT)
|
||||
* [Locking Block Device Access](https://systemd.io/BLOCK_DEVICE_LOCKING)
|
||||
* [The Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE)
|
||||
* [The Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)
|
||||
* [Control Group APIs and Delegation](https://systemd.io/CGROUP_DELEGATION)
|
||||
* [The systemd Community Conduct Guidelines](https://github.com/systemd/systemd/blob/master/docs/CODE_OF_CONDUCT.md)
|
||||
* [Code Quality Tools](https://systemd.io/CODE_QUALITY)
|
||||
* [Coding Style](https://systemd.io/CODING_STYLE)
|
||||
* [Contributing](https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md)
|
||||
* [Porting systemd To New Distributions](https://systemd.io/DISTRO_PORTING)
|
||||
* [Predictable Network Interface Names](https://systemd.io/PREDICTABLE_INTERFACE_NAMES)
|
||||
* [Known Environment Variables](https://systemd.io/ENVIRONMENT)
|
||||
* [Hacking on systemd](https://systemd.io/HACKING)
|
||||
* [Portable Services Introduction](https://systemd.io/PORTABLE_SERVICES)
|
||||
* [Steps to a Successful Release](https://systemd.io/RELEASE)
|
||||
* [What settings are currently available for transient units?](https://systemd.io/TRANSIENT-SETTINGS)
|
||||
* [Notes for Translators](https://systemd.io/TRANSLATORS)
|
||||
* [Users, Groups, UIDs and GIDs on `systemd` Systems](https://systemd.io/UIDS-GIDS)
|
||||
@ -1,6 +1,15 @@
|
||||
# This file is part of systemd.
|
||||
|
||||
passwd: files
|
||||
shadow: files
|
||||
group: files
|
||||
hosts: files mymachines resolve myhostname
|
||||
passwd: compat mymachines systemd
|
||||
group: compat mymachines systemd
|
||||
shadow: compat
|
||||
|
||||
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
|
||||
networks: files
|
||||
|
||||
protocols: db files
|
||||
services: db files
|
||||
ethers: db files
|
||||
rpc: db files
|
||||
|
||||
netgroup: nis
|
||||
|
||||
4281
hwdb/20-OUI.hwdb
4281
hwdb/20-OUI.hwdb
File diff suppressed because it is too large
Load Diff
@ -54,6 +54,9 @@ acpi:BOSC*:
|
||||
acpi:BRCM*:
|
||||
ID_VENDOR_FROM_DATABASE=Broadcom Corporation
|
||||
|
||||
acpi:CMHR*:
|
||||
ID_VENDOR_FROM_DATABASE=COMHEAR, INC.
|
||||
|
||||
acpi:CORE*:
|
||||
ID_VENDOR_FROM_DATABASE=CoreOS, Inc
|
||||
|
||||
@ -69,6 +72,9 @@ acpi:DLGS*:
|
||||
acpi:DLLK*:
|
||||
ID_VENDOR_FROM_DATABASE=Dell, Inc.
|
||||
|
||||
acpi:DMST*:
|
||||
ID_VENDOR_FROM_DATABASE=DMIST RESEARCH LTD
|
||||
|
||||
acpi:DSUO*:
|
||||
ID_VENDOR_FROM_DATABASE=Shenzhen DSO Microelectronics Co.,Ltd.
|
||||
|
||||
@ -93,6 +99,9 @@ acpi:GHSW*:
|
||||
acpi:GOOG*:
|
||||
ID_VENDOR_FROM_DATABASE=Google, Inc.
|
||||
|
||||
acpi:GTCH*:
|
||||
ID_VENDOR_FROM_DATABASE=G2touch Co., LTD
|
||||
|
||||
acpi:HIMX*:
|
||||
ID_VENDOR_FROM_DATABASE=Himax Technologies, Inc.
|
||||
|
||||
@ -117,6 +126,9 @@ acpi:IBMX*:
|
||||
acpi:IDEA*:
|
||||
ID_VENDOR_FROM_DATABASE=Lenovo Beijing Co. Ltd.
|
||||
|
||||
acpi:IDEM*:
|
||||
ID_VENDOR_FROM_DATABASE=IDEMIA
|
||||
|
||||
acpi:IHSE*:
|
||||
ID_VENDOR_FROM_DATABASE=IHSE GmbH
|
||||
|
||||
@ -210,6 +222,9 @@ acpi:RZSN*:
|
||||
acpi:SHRP*:
|
||||
ID_VENDOR_FROM_DATABASE=Sharp Corporation
|
||||
|
||||
acpi:SNSL*:
|
||||
ID_VENDOR_FROM_DATABASE=Sensel, Inc.
|
||||
|
||||
acpi:SONY*:
|
||||
ID_VENDOR_FROM_DATABASE=Sony Corporation
|
||||
|
||||
@ -240,6 +255,9 @@ acpi:VAIO*:
|
||||
acpi:VFSI*:
|
||||
ID_VENDOR_FROM_DATABASE=Validity Sensors, Inc
|
||||
|
||||
acpi:VSHY*:
|
||||
ID_VENDOR_FROM_DATABASE=Vishay Intertechnology, Inc.
|
||||
|
||||
acpi:WCOM*:
|
||||
ID_VENDOR_FROM_DATABASE=Wacom
|
||||
|
||||
@ -450,6 +468,9 @@ acpi:AGT*:
|
||||
acpi:AHC*:
|
||||
ID_VENDOR_FROM_DATABASE=Advantech Co., Ltd.
|
||||
|
||||
acpi:AHQ*:
|
||||
ID_VENDOR_FROM_DATABASE=Astro HQ LLC
|
||||
|
||||
acpi:AHS*:
|
||||
ID_VENDOR_FROM_DATABASE=Beijing AnHeng SecoTech Information Technology Co., Ltd.
|
||||
|
||||
@ -1371,6 +1392,9 @@ acpi:CHY*:
|
||||
acpi:CIC*:
|
||||
ID_VENDOR_FROM_DATABASE=Comm. Intelligence Corporation
|
||||
|
||||
acpi:CIE*:
|
||||
ID_VENDOR_FROM_DATABASE=Convergent Engineering, Inc.
|
||||
|
||||
acpi:CII*:
|
||||
ID_VENDOR_FROM_DATABASE=Cromack Industries Inc
|
||||
|
||||
@ -2697,6 +2721,9 @@ acpi:GAL*:
|
||||
acpi:GAU*:
|
||||
ID_VENDOR_FROM_DATABASE=Gaudi Co., Ltd.
|
||||
|
||||
acpi:GBT*:
|
||||
ID_VENDOR_FROM_DATABASE=GIGA-BYTE TECHNOLOGY CO., LTD.
|
||||
|
||||
acpi:GCC*:
|
||||
ID_VENDOR_FROM_DATABASE=GCC Technologies Inc
|
||||
|
||||
@ -2842,7 +2869,7 @@ acpi:GSC*:
|
||||
ID_VENDOR_FROM_DATABASE=General Standards Corporation
|
||||
|
||||
acpi:GSM*:
|
||||
ID_VENDOR_FROM_DATABASE=Goldstar Company Ltd
|
||||
ID_VENDOR_FROM_DATABASE=LG Electronics
|
||||
|
||||
acpi:GSN*:
|
||||
ID_VENDOR_FROM_DATABASE=Grandstream Networks, Inc.
|
||||
@ -3753,6 +3780,9 @@ acpi:KOE*:
|
||||
acpi:KOL*:
|
||||
ID_VENDOR_FROM_DATABASE=Kollmorgen Motion Technologies Group
|
||||
|
||||
acpi:KOM*:
|
||||
ID_VENDOR_FROM_DATABASE=Kontron GmbH
|
||||
|
||||
acpi:KOU*:
|
||||
ID_VENDOR_FROM_DATABASE=KOUZIRO Co.,Ltd.
|
||||
|
||||
@ -4152,6 +4182,9 @@ acpi:MCG*:
|
||||
acpi:MCI*:
|
||||
ID_VENDOR_FROM_DATABASE=Micronics Computers
|
||||
|
||||
acpi:MCJ*:
|
||||
ID_VENDOR_FROM_DATABASE=Medicaroid Corporation
|
||||
|
||||
acpi:MCL*:
|
||||
ID_VENDOR_FROM_DATABASE=Motorola Communications Israel
|
||||
|
||||
@ -5778,6 +5811,9 @@ acpi:RWC*:
|
||||
acpi:RXT*:
|
||||
ID_VENDOR_FROM_DATABASE=Tectona SoftSolutions (P) Ltd.,
|
||||
|
||||
acpi:RZR*:
|
||||
ID_VENDOR_FROM_DATABASE=Razer Taiwan Co. Ltd.
|
||||
|
||||
acpi:RZS*:
|
||||
ID_VENDOR_FROM_DATABASE=Rozsnyó, s.r.o.
|
||||
|
||||
@ -7089,6 +7125,9 @@ acpi:VAL*:
|
||||
acpi:VAR*:
|
||||
ID_VENDOR_FROM_DATABASE=Varian Australia Pty Ltd
|
||||
|
||||
acpi:VAT*:
|
||||
ID_VENDOR_FROM_DATABASE=VADATECH INC
|
||||
|
||||
acpi:VBR*:
|
||||
ID_VENDOR_FROM_DATABASE=VBrick Systems Inc.
|
||||
|
||||
@ -7366,7 +7405,7 @@ acpi:WNV*:
|
||||
ID_VENDOR_FROM_DATABASE=Winnov L.P.
|
||||
|
||||
acpi:WNX*:
|
||||
ID_VENDOR_FROM_DATABASE=Wincor Nixdorf International GmbH
|
||||
ID_VENDOR_FROM_DATABASE=Diebold Nixdorf Systems GmbH
|
||||
|
||||
acpi:WPA*:
|
||||
ID_VENDOR_FROM_DATABASE=Matsushita Communication Industrial Co., Ltd.
|
||||
@ -7413,6 +7452,9 @@ acpi:WWV*:
|
||||
acpi:WXT*:
|
||||
ID_VENDOR_FROM_DATABASE=Woxter Technology Co. Ltd
|
||||
|
||||
acpi:WYR*:
|
||||
ID_VENDOR_FROM_DATABASE=WyreStorm Technologies LLC
|
||||
|
||||
acpi:WYS*:
|
||||
ID_VENDOR_FROM_DATABASE=Wyse Technology
|
||||
|
||||
@ -7516,7 +7558,7 @@ acpi:ZAX*:
|
||||
ID_VENDOR_FROM_DATABASE=Zefiro Acoustics
|
||||
|
||||
acpi:ZAZ*:
|
||||
ID_VENDOR_FROM_DATABASE=Zazzle Technologies
|
||||
ID_VENDOR_FROM_DATABASE=ZeeVee, Inc.
|
||||
|
||||
acpi:ZBR*:
|
||||
ID_VENDOR_FROM_DATABASE=Zebra Technologies International, LLC
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
--- 20-acpi-vendor.hwdb.base 2018-06-12 15:51:50.897235123 +0200
|
||||
+++ 20-acpi-vendor.hwdb 2018-06-12 15:51:50.907235139 +0200
|
||||
--- 20-acpi-vendor.hwdb.base 2018-12-20 16:29:34.999977602 +0100
|
||||
+++ 20-acpi-vendor.hwdb 2018-12-20 16:29:35.022977859 +0100
|
||||
@@ -3,6 +3,8 @@
|
||||
# Data imported from:
|
||||
# http://www.uefi.org/uefi-pnp-export
|
||||
@ -19,7 +19,7 @@
|
||||
acpi:AMDI*:
|
||||
ID_VENDOR_FROM_DATABASE=AMD
|
||||
|
||||
@@ -253,6 +252,9 @@
|
||||
@@ -271,6 +270,9 @@
|
||||
acpi:AAA*:
|
||||
ID_VENDOR_FROM_DATABASE=Avolites Ltd
|
||||
|
||||
@ -29,7 +29,7 @@
|
||||
acpi:AAE*:
|
||||
ID_VENDOR_FROM_DATABASE=Anatek Electronics Inc.
|
||||
|
||||
@@ -280,6 +282,9 @@
|
||||
@@ -298,6 +300,9 @@
|
||||
acpi:ABO*:
|
||||
ID_VENDOR_FROM_DATABASE=D-Link Systems Inc
|
||||
|
||||
@ -39,7 +39,7 @@
|
||||
acpi:ABS*:
|
||||
ID_VENDOR_FROM_DATABASE=Abaco Systems, Inc.
|
||||
|
||||
@@ -325,7 +330,7 @@
|
||||
@@ -343,7 +348,7 @@
|
||||
acpi:ACO*:
|
||||
ID_VENDOR_FROM_DATABASE=Allion Computer Inc.
|
||||
|
||||
@ -48,7 +48,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Aspen Tech Inc
|
||||
|
||||
acpi:ACR*:
|
||||
@@ -595,6 +600,9 @@
|
||||
@@ -616,6 +621,9 @@
|
||||
acpi:AMT*:
|
||||
ID_VENDOR_FROM_DATABASE=AMT International Industry
|
||||
|
||||
@ -58,7 +58,7 @@
|
||||
acpi:AMX*:
|
||||
ID_VENDOR_FROM_DATABASE=AMX LLC
|
||||
|
||||
@@ -643,6 +651,9 @@
|
||||
@@ -664,6 +672,9 @@
|
||||
acpi:AOA*:
|
||||
ID_VENDOR_FROM_DATABASE=AOpen Inc.
|
||||
|
||||
@ -68,7 +68,7 @@
|
||||
acpi:AOE*:
|
||||
ID_VENDOR_FROM_DATABASE=Advanced Optics Electronics, Inc.
|
||||
|
||||
@@ -652,6 +663,9 @@
|
||||
@@ -673,6 +684,9 @@
|
||||
acpi:AOT*:
|
||||
ID_VENDOR_FROM_DATABASE=Alcatel
|
||||
|
||||
@ -78,7 +78,7 @@
|
||||
acpi:APC*:
|
||||
ID_VENDOR_FROM_DATABASE=American Power Conversion
|
||||
|
||||
@@ -827,7 +841,7 @@
|
||||
@@ -848,7 +862,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Alps Electric Inc
|
||||
|
||||
acpi:AUO*:
|
||||
@ -87,7 +87,7 @@
|
||||
|
||||
acpi:AUR*:
|
||||
ID_VENDOR_FROM_DATABASE=Aureal Semiconductor
|
||||
@@ -907,6 +921,9 @@
|
||||
@@ -928,6 +942,9 @@
|
||||
acpi:AXE*:
|
||||
ID_VENDOR_FROM_DATABASE=Axell Corporation
|
||||
|
||||
@ -97,7 +97,7 @@
|
||||
acpi:AXI*:
|
||||
ID_VENDOR_FROM_DATABASE=American Magnetics
|
||||
|
||||
@@ -1054,6 +1071,9 @@
|
||||
@@ -1075,6 +1092,9 @@
|
||||
acpi:BML*:
|
||||
ID_VENDOR_FROM_DATABASE=BIOMED Lab
|
||||
|
||||
@ -107,7 +107,7 @@
|
||||
acpi:BMS*:
|
||||
ID_VENDOR_FROM_DATABASE=BIOMEDISYS
|
||||
|
||||
@@ -1066,6 +1086,9 @@
|
||||
@@ -1087,6 +1107,9 @@
|
||||
acpi:BNO*:
|
||||
ID_VENDOR_FROM_DATABASE=Bang & Olufsen
|
||||
|
||||
@ -117,7 +117,7 @@
|
||||
acpi:BNS*:
|
||||
ID_VENDOR_FROM_DATABASE=Boulder Nonlinear Systems
|
||||
|
||||
@@ -1306,6 +1329,9 @@
|
||||
@@ -1327,6 +1350,9 @@
|
||||
acpi:CHA*:
|
||||
ID_VENDOR_FROM_DATABASE=Chase Research PLC
|
||||
|
||||
@ -127,7 +127,7 @@
|
||||
acpi:CHD*:
|
||||
ID_VENDOR_FROM_DATABASE=ChangHong Electric Co.,Ltd
|
||||
|
||||
@@ -1456,6 +1482,9 @@
|
||||
@@ -1480,6 +1506,9 @@
|
||||
acpi:COD*:
|
||||
ID_VENDOR_FROM_DATABASE=CODAN Pty. Ltd.
|
||||
|
||||
@ -137,7 +137,7 @@
|
||||
acpi:COI*:
|
||||
ID_VENDOR_FROM_DATABASE=Codec Inc.
|
||||
|
||||
@@ -1859,7 +1888,7 @@
|
||||
@@ -1883,7 +1912,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Dragon Information Technology
|
||||
|
||||
acpi:DJE*:
|
||||
@ -146,7 +146,7 @@
|
||||
|
||||
acpi:DJP*:
|
||||
ID_VENDOR_FROM_DATABASE=Maygay Machines, Ltd
|
||||
@@ -2182,6 +2211,9 @@
|
||||
@@ -2206,6 +2235,9 @@
|
||||
acpi:EIN*:
|
||||
ID_VENDOR_FROM_DATABASE=Elegant Invention
|
||||
|
||||
@ -156,7 +156,7 @@
|
||||
acpi:EKA*:
|
||||
ID_VENDOR_FROM_DATABASE=MagTek Inc.
|
||||
|
||||
@@ -2440,6 +2472,9 @@
|
||||
@@ -2464,6 +2496,9 @@
|
||||
acpi:FCG*:
|
||||
ID_VENDOR_FROM_DATABASE=First International Computer Ltd
|
||||
|
||||
@ -166,7 +166,16 @@
|
||||
acpi:FCS*:
|
||||
ID_VENDOR_FROM_DATABASE=Focus Enhancements, Inc.
|
||||
|
||||
@@ -2908,6 +2943,9 @@
|
||||
@@ -2834,7 +2869,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=General Standards Corporation
|
||||
|
||||
acpi:GSM*:
|
||||
- ID_VENDOR_FROM_DATABASE=Goldstar Company Ltd
|
||||
+ ID_VENDOR_FROM_DATABASE=LG Electronics
|
||||
|
||||
acpi:GSN*:
|
||||
ID_VENDOR_FROM_DATABASE=Grandstream Networks, Inc.
|
||||
@@ -2935,6 +2970,9 @@
|
||||
acpi:HEC*:
|
||||
ID_VENDOR_FROM_DATABASE=Hisense Electric Co., Ltd.
|
||||
|
||||
@ -176,7 +185,7 @@
|
||||
acpi:HEL*:
|
||||
ID_VENDOR_FROM_DATABASE=Hitachi Micro Systems Europe Ltd
|
||||
|
||||
@@ -3037,6 +3075,9 @@
|
||||
@@ -3064,6 +3102,9 @@
|
||||
acpi:HSD*:
|
||||
ID_VENDOR_FROM_DATABASE=HannStar Display Corp
|
||||
|
||||
@ -186,7 +195,7 @@
|
||||
acpi:HSM*:
|
||||
ID_VENDOR_FROM_DATABASE=AT&T Microelectronics
|
||||
|
||||
@@ -3160,6 +3201,9 @@
|
||||
@@ -3187,6 +3228,9 @@
|
||||
acpi:ICI*:
|
||||
ID_VENDOR_FROM_DATABASE=Infotek Communication Inc
|
||||
|
||||
@ -196,7 +205,7 @@
|
||||
acpi:ICM*:
|
||||
ID_VENDOR_FROM_DATABASE=Intracom SA
|
||||
|
||||
@@ -3253,6 +3297,9 @@
|
||||
@@ -3280,6 +3324,9 @@
|
||||
acpi:IKE*:
|
||||
ID_VENDOR_FROM_DATABASE=Ikegami Tsushinki Co. Ltd.
|
||||
|
||||
@ -206,7 +215,7 @@
|
||||
acpi:IKS*:
|
||||
ID_VENDOR_FROM_DATABASE=Ikos Systems Inc
|
||||
|
||||
@@ -3298,6 +3345,9 @@
|
||||
@@ -3325,6 +3372,9 @@
|
||||
acpi:IMT*:
|
||||
ID_VENDOR_FROM_DATABASE=Inmax Technology Corporation
|
||||
|
||||
@ -216,7 +225,7 @@
|
||||
acpi:INA*:
|
||||
ID_VENDOR_FROM_DATABASE=Inventec Corporation
|
||||
|
||||
@@ -3802,6 +3852,9 @@
|
||||
@@ -3832,6 +3882,9 @@
|
||||
acpi:LAN*:
|
||||
ID_VENDOR_FROM_DATABASE=Sodeman Lancom Inc
|
||||
|
||||
@ -226,7 +235,7 @@
|
||||
acpi:LAS*:
|
||||
ID_VENDOR_FROM_DATABASE=LASAT Comm. A/S
|
||||
|
||||
@@ -3847,6 +3900,9 @@
|
||||
@@ -3877,6 +3930,9 @@
|
||||
acpi:LED*:
|
||||
ID_VENDOR_FROM_DATABASE=Long Engineering Design Inc
|
||||
|
||||
@ -236,7 +245,7 @@
|
||||
acpi:LEG*:
|
||||
ID_VENDOR_FROM_DATABASE=Legerity, Inc
|
||||
|
||||
@@ -3862,6 +3918,9 @@
|
||||
@@ -3892,6 +3948,9 @@
|
||||
acpi:LGC*:
|
||||
ID_VENDOR_FROM_DATABASE=Logic Ltd
|
||||
|
||||
@ -246,7 +255,7 @@
|
||||
acpi:LGI*:
|
||||
ID_VENDOR_FROM_DATABASE=Logitech Inc
|
||||
|
||||
@@ -3913,6 +3972,9 @@
|
||||
@@ -3943,6 +4002,9 @@
|
||||
acpi:LND*:
|
||||
ID_VENDOR_FROM_DATABASE=Land Computer Company Ltd
|
||||
|
||||
@ -256,7 +265,7 @@
|
||||
acpi:LNK*:
|
||||
ID_VENDOR_FROM_DATABASE=Link Tech Inc
|
||||
|
||||
@@ -3947,7 +4009,7 @@
|
||||
@@ -3977,7 +4039,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Design Technology
|
||||
|
||||
acpi:LPL*:
|
||||
@ -265,7 +274,7 @@
|
||||
|
||||
acpi:LSC*:
|
||||
ID_VENDOR_FROM_DATABASE=LifeSize Communications
|
||||
@@ -4120,6 +4182,9 @@
|
||||
@@ -4153,6 +4215,9 @@
|
||||
acpi:MCX*:
|
||||
ID_VENDOR_FROM_DATABASE=Millson Custom Solutions Inc.
|
||||
|
||||
@ -275,7 +284,7 @@
|
||||
acpi:MDA*:
|
||||
ID_VENDOR_FROM_DATABASE=Media4 Inc
|
||||
|
||||
@@ -4351,6 +4416,9 @@
|
||||
@@ -4384,6 +4449,9 @@
|
||||
acpi:MOM*:
|
||||
ID_VENDOR_FROM_DATABASE=Momentum Data Systems
|
||||
|
||||
@ -285,7 +294,7 @@
|
||||
acpi:MOS*:
|
||||
ID_VENDOR_FROM_DATABASE=Moses Corporation
|
||||
|
||||
@@ -4576,6 +4644,9 @@
|
||||
@@ -4609,6 +4677,9 @@
|
||||
acpi:NAL*:
|
||||
ID_VENDOR_FROM_DATABASE=Network Alchemy
|
||||
|
||||
@ -295,7 +304,7 @@
|
||||
acpi:NAT*:
|
||||
ID_VENDOR_FROM_DATABASE=NaturalPoint Inc.
|
||||
|
||||
@@ -5080,6 +5151,9 @@
|
||||
@@ -5113,6 +5184,9 @@
|
||||
acpi:PCX*:
|
||||
ID_VENDOR_FROM_DATABASE=PC Xperten
|
||||
|
||||
@ -305,7 +314,7 @@
|
||||
acpi:PDM*:
|
||||
ID_VENDOR_FROM_DATABASE=Psion Dacom Plc.
|
||||
|
||||
@@ -5143,9 +5217,6 @@
|
||||
@@ -5176,9 +5250,6 @@
|
||||
acpi:PHE*:
|
||||
ID_VENDOR_FROM_DATABASE=Philips Medical Systems Boeblingen GmbH
|
||||
|
||||
@ -315,7 +324,7 @@
|
||||
acpi:PHL*:
|
||||
ID_VENDOR_FROM_DATABASE=Philips Consumer Electronics Company
|
||||
|
||||
@@ -5230,9 +5301,6 @@
|
||||
@@ -5263,9 +5334,6 @@
|
||||
acpi:PNL*:
|
||||
ID_VENDOR_FROM_DATABASE=Panelview, Inc.
|
||||
|
||||
@ -325,7 +334,7 @@
|
||||
acpi:PNR*:
|
||||
ID_VENDOR_FROM_DATABASE=Planar Systems, Inc.
|
||||
|
||||
@@ -5368,15 +5436,9 @@
|
||||
@@ -5401,15 +5469,9 @@
|
||||
acpi:PTS*:
|
||||
ID_VENDOR_FROM_DATABASE=Plain Tree Systems Inc
|
||||
|
||||
@ -341,7 +350,7 @@
|
||||
acpi:PVG*:
|
||||
ID_VENDOR_FROM_DATABASE=Proview Global Co., Ltd
|
||||
|
||||
@@ -5689,9 +5751,6 @@
|
||||
@@ -5722,9 +5784,6 @@
|
||||
acpi:RTI*:
|
||||
ID_VENDOR_FROM_DATABASE=Rancho Tech Inc
|
||||
|
||||
@ -351,7 +360,7 @@
|
||||
acpi:RTL*:
|
||||
ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Company Ltd
|
||||
|
||||
@@ -5854,9 +5913,6 @@
|
||||
@@ -5890,9 +5949,6 @@
|
||||
acpi:SEE*:
|
||||
ID_VENDOR_FROM_DATABASE=SeeColor Corporation
|
||||
|
||||
@ -361,7 +370,7 @@
|
||||
acpi:SEI*:
|
||||
ID_VENDOR_FROM_DATABASE=Seitz & Associates Inc
|
||||
|
||||
@@ -6310,6 +6366,9 @@
|
||||
@@ -6346,6 +6402,9 @@
|
||||
acpi:SVD*:
|
||||
ID_VENDOR_FROM_DATABASE=SVD Computer
|
||||
|
||||
@ -371,7 +380,7 @@
|
||||
acpi:SVI*:
|
||||
ID_VENDOR_FROM_DATABASE=Sun Microsystems
|
||||
|
||||
@@ -6394,6 +6453,9 @@
|
||||
@@ -6430,6 +6489,9 @@
|
||||
acpi:SZM*:
|
||||
ID_VENDOR_FROM_DATABASE=Shenzhen MTC Co., Ltd
|
||||
|
||||
@ -381,7 +390,7 @@
|
||||
acpi:TAA*:
|
||||
ID_VENDOR_FROM_DATABASE=Tandberg
|
||||
|
||||
@@ -6484,6 +6546,9 @@
|
||||
@@ -6520,6 +6582,9 @@
|
||||
acpi:TDG*:
|
||||
ID_VENDOR_FROM_DATABASE=Six15 Technologies
|
||||
|
||||
@ -391,7 +400,7 @@
|
||||
acpi:TDM*:
|
||||
ID_VENDOR_FROM_DATABASE=Tandem Computer Europe Inc
|
||||
|
||||
@@ -6526,6 +6591,9 @@
|
||||
@@ -6562,6 +6627,9 @@
|
||||
acpi:TEV*:
|
||||
ID_VENDOR_FROM_DATABASE=Televés, S.A.
|
||||
|
||||
@ -401,7 +410,7 @@
|
||||
acpi:TEZ*:
|
||||
ID_VENDOR_FROM_DATABASE=Tech Source Inc.
|
||||
|
||||
@@ -6640,9 +6708,6 @@
|
||||
@@ -6676,9 +6744,6 @@
|
||||
acpi:TNC*:
|
||||
ID_VENDOR_FROM_DATABASE=TNC Industrial Company Ltd
|
||||
|
||||
@ -411,7 +420,7 @@
|
||||
acpi:TNM*:
|
||||
ID_VENDOR_FROM_DATABASE=TECNIMAGEN SA
|
||||
|
||||
@@ -6949,14 +7014,14 @@
|
||||
@@ -6985,14 +7050,14 @@
|
||||
acpi:UNC*:
|
||||
ID_VENDOR_FROM_DATABASE=Unisys Corporation
|
||||
|
||||
@ -432,7 +441,7 @@
|
||||
|
||||
acpi:UNI*:
|
||||
ID_VENDOR_FROM_DATABASE=Uniform Industry Corp.
|
||||
@@ -6991,6 +7056,9 @@
|
||||
@@ -7027,6 +7092,9 @@
|
||||
acpi:USA*:
|
||||
ID_VENDOR_FROM_DATABASE=Utimaco Safeware AG
|
||||
|
||||
@ -442,7 +451,7 @@
|
||||
acpi:USD*:
|
||||
ID_VENDOR_FROM_DATABASE=U.S. Digital Corporation
|
||||
|
||||
@@ -7228,9 +7296,6 @@
|
||||
@@ -7267,9 +7335,6 @@
|
||||
acpi:WAL*:
|
||||
ID_VENDOR_FROM_DATABASE=Wave Access
|
||||
|
||||
@ -452,8 +461,8 @@
|
||||
acpi:WAV*:
|
||||
ID_VENDOR_FROM_DATABASE=Wavephore
|
||||
|
||||
@@ -7349,7 +7414,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Woxter Technology Co. Ltd
|
||||
@@ -7391,7 +7456,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=WyreStorm Technologies LLC
|
||||
|
||||
acpi:WYS*:
|
||||
- ID_VENDOR_FROM_DATABASE=Myse Technology
|
||||
@ -461,7 +470,7 @@
|
||||
|
||||
acpi:WYT*:
|
||||
ID_VENDOR_FROM_DATABASE=Wooyoung Image & Information Co.,Ltd.
|
||||
@@ -7363,9 +7428,6 @@
|
||||
@@ -7405,9 +7470,6 @@
|
||||
acpi:XDM*:
|
||||
ID_VENDOR_FROM_DATABASE=XDM Ltd.
|
||||
|
||||
@ -471,7 +480,7 @@
|
||||
acpi:XES*:
|
||||
ID_VENDOR_FROM_DATABASE=Extreme Engineering Solutions, Inc.
|
||||
|
||||
@@ -7396,9 +7458,6 @@
|
||||
@@ -7438,9 +7500,6 @@
|
||||
acpi:XNT*:
|
||||
ID_VENDOR_FROM_DATABASE=XN Technologies, Inc.
|
||||
|
||||
@ -481,7 +490,7 @@
|
||||
acpi:XQU*:
|
||||
ID_VENDOR_FROM_DATABASE=SHANGHAI SVA-DAV ELECTRONICS CO., LTD
|
||||
|
||||
@@ -7465,6 +7524,9 @@
|
||||
@@ -7507,6 +7566,9 @@
|
||||
acpi:ZBX*:
|
||||
ID_VENDOR_FROM_DATABASE=Zebax Technologies
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -2291,6 +2291,9 @@ usb:v0403p8371*
|
||||
usb:v0403p8372*
|
||||
ID_MODEL_FROM_DATABASE=FT8U100AX Serial Port
|
||||
|
||||
usb:v0403p87D0*
|
||||
ID_MODEL_FROM_DATABASE=Cressi Dive Computer Interface
|
||||
|
||||
usb:v0403p8A28*
|
||||
ID_MODEL_FROM_DATABASE=Rainforest Automation ZigBee Controller
|
||||
|
||||
@ -2387,6 +2390,9 @@ usb:v0403pBCD9*
|
||||
usb:v0403pBCDA*
|
||||
ID_MODEL_FROM_DATABASE=Stellaris ICDI Board
|
||||
|
||||
usb:v0403pBD90*
|
||||
ID_MODEL_FROM_DATABASE=PICAXE Download Cable [AXE027]
|
||||
|
||||
usb:v0403pBDC8*
|
||||
ID_MODEL_FROM_DATABASE=Egnite GmbH - JTAG/RS-232 adapter
|
||||
|
||||
@ -3515,6 +3521,9 @@ usb:v0411p00DB*
|
||||
usb:v0411p00E8*
|
||||
ID_MODEL_FROM_DATABASE=WLI-UC-G300N Wireless LAN Adapter [Ralink RT2870]
|
||||
|
||||
usb:v0411p00F9*
|
||||
ID_MODEL_FROM_DATABASE=Portable DVD Writer (DVSM-PL58U2)
|
||||
|
||||
usb:v0411p0105*
|
||||
ID_MODEL_FROM_DATABASE=External Hard Drive HD-CEU2 [Drive Station]
|
||||
|
||||
@ -3554,12 +3563,18 @@ usb:v0411p01A1*
|
||||
usb:v0411p01A2*
|
||||
ID_MODEL_FROM_DATABASE=WLI-UC-GNM Wireless LAN Adapter [Ralink RT8070]
|
||||
|
||||
usb:v0411p01BA*
|
||||
ID_MODEL_FROM_DATABASE=SATA Bridge
|
||||
|
||||
usb:v0411p01DC*
|
||||
ID_MODEL_FROM_DATABASE=Ultra-Slim Portable DVD Writer (DVSM-PC58U2V)
|
||||
|
||||
usb:v0411p01DE*
|
||||
ID_MODEL_FROM_DATABASE=External Hard Drive HD-PCTU3 [Buffalo MiniStation]
|
||||
|
||||
usb:v0411p01EA*
|
||||
ID_MODEL_FROM_DATABASE=SATA Bridge
|
||||
|
||||
usb:v0411p01EE*
|
||||
ID_MODEL_FROM_DATABASE=WLI-UC-GNM2 Wireless LAN Adapter [Ralink RT3070]
|
||||
|
||||
@ -3569,6 +3584,9 @@ usb:v0411p01F1*
|
||||
usb:v0411p01FD*
|
||||
ID_MODEL_FROM_DATABASE=WLI-UC-G450 Wireless LAN Adapter
|
||||
|
||||
usb:v0411p027E*
|
||||
ID_MODEL_FROM_DATABASE=HD-LCU3
|
||||
|
||||
usb:v0412*
|
||||
ID_VENDOR_FROM_DATABASE=Award Software International
|
||||
|
||||
@ -3896,6 +3914,9 @@ usb:v041Ep3220*
|
||||
usb:v041Ep3232*
|
||||
ID_MODEL_FROM_DATABASE=Sound Blaster Premium HD [SBX]
|
||||
|
||||
usb:v041Ep3237*
|
||||
ID_MODEL_FROM_DATABASE=SB X-Fi Surround 5.1 Pro
|
||||
|
||||
usb:v041Ep3F00*
|
||||
ID_MODEL_FROM_DATABASE=E-Mu Xboard 25 MIDI Controller
|
||||
|
||||
@ -5753,6 +5774,9 @@ usb:v0451p8142*
|
||||
usb:v0451p926B*
|
||||
ID_MODEL_FROM_DATABASE=TUSB9260 Boot Loader
|
||||
|
||||
usb:v0451pBEF3*
|
||||
ID_MODEL_FROM_DATABASE=CC1352R1 Launchpad
|
||||
|
||||
usb:v0451pDBC0*
|
||||
ID_MODEL_FROM_DATABASE=Device Bay Controller
|
||||
|
||||
@ -7088,6 +7112,9 @@ usb:v045Ep0799*
|
||||
usb:v045Ep07A5*
|
||||
ID_MODEL_FROM_DATABASE=Wireless Receiver 1461C
|
||||
|
||||
usb:v045Ep07B2*
|
||||
ID_MODEL_FROM_DATABASE=2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900
|
||||
|
||||
usb:v045Ep07B9*
|
||||
ID_MODEL_FROM_DATABASE=Wired Keyboard 200
|
||||
|
||||
@ -7133,6 +7160,9 @@ usb:v045Ep090C*
|
||||
usb:v045Ep091A*
|
||||
ID_MODEL_FROM_DATABASE=Hub
|
||||
|
||||
usb:v045Ep09C0*
|
||||
ID_MODEL_FROM_DATABASE=Surface Type Cover
|
||||
|
||||
usb:v045Ep0A00*
|
||||
ID_MODEL_FROM_DATABASE=Lumia 950 Dual SIM (RM-1118)
|
||||
|
||||
@ -7334,6 +7364,12 @@ usb:v0461p4D75*
|
||||
usb:v0461p4D81*
|
||||
ID_MODEL_FROM_DATABASE=Dell N889 Optical Mouse
|
||||
|
||||
usb:v0461p4D91*
|
||||
ID_MODEL_FROM_DATABASE=Laser mouse M-D16DL
|
||||
|
||||
usb:v0461p4D92*
|
||||
ID_MODEL_FROM_DATABASE=Optical mouse M-D17DR
|
||||
|
||||
usb:v0461p4DE3*
|
||||
ID_MODEL_FROM_DATABASE=HP 5-Button Optical Comfort Mouse
|
||||
|
||||
@ -7517,6 +7553,9 @@ usb:v046Dp0810*
|
||||
usb:v046Dp0819*
|
||||
ID_MODEL_FROM_DATABASE=Webcam C210
|
||||
|
||||
usb:v046Dp081A*
|
||||
ID_MODEL_FROM_DATABASE=Webcam C260
|
||||
|
||||
usb:v046Dp081B*
|
||||
ID_MODEL_FROM_DATABASE=Webcam C310
|
||||
|
||||
@ -8126,6 +8165,9 @@ usb:v046DpC07E*
|
||||
usb:v046DpC083*
|
||||
ID_MODEL_FROM_DATABASE=G403 Prodigy Gaming Mouse
|
||||
|
||||
usb:v046DpC084*
|
||||
ID_MODEL_FROM_DATABASE=G203 Gaming Mouse
|
||||
|
||||
usb:v046DpC101*
|
||||
ID_MODEL_FROM_DATABASE=UltraX Media Remote
|
||||
|
||||
@ -8414,6 +8456,9 @@ usb:v046DpC31D*
|
||||
usb:v046DpC31F*
|
||||
ID_MODEL_FROM_DATABASE=Comfort Keyboard K290
|
||||
|
||||
usb:v046DpC326*
|
||||
ID_MODEL_FROM_DATABASE=Washable Keyboard K310
|
||||
|
||||
usb:v046DpC328*
|
||||
ID_MODEL_FROM_DATABASE=Corded Keyboard K280e
|
||||
|
||||
@ -8423,6 +8468,9 @@ usb:v046DpC332*
|
||||
usb:v046DpC335*
|
||||
ID_MODEL_FROM_DATABASE=G910 Orion Spectrum Mechanical Keyboard
|
||||
|
||||
usb:v046DpC33A*
|
||||
ID_MODEL_FROM_DATABASE=G413 Gaming Keyboard
|
||||
|
||||
usb:v046DpC401*
|
||||
ID_MODEL_FROM_DATABASE=TrackMan Marble Wheel
|
||||
|
||||
@ -9416,6 +9464,9 @@ usb:v047FpAC01*
|
||||
usb:v047FpAD01*
|
||||
ID_MODEL_FROM_DATABASE=GameCom 777 5.1 Headset
|
||||
|
||||
usb:v047FpAF01*
|
||||
ID_MODEL_FROM_DATABASE=DA80
|
||||
|
||||
usb:v047FpC008*
|
||||
ID_MODEL_FROM_DATABASE=Audio 655 DSP
|
||||
|
||||
@ -9458,6 +9509,9 @@ usb:v0480pA00D*
|
||||
usb:v0480pA100*
|
||||
ID_MODEL_FROM_DATABASE=Canvio Alu 2TB 2.5" Black External Disk Model HDTH320EK3CA
|
||||
|
||||
usb:v0480pA102*
|
||||
ID_MODEL_FROM_DATABASE=Canvio Alu 2TB 2.5" Black External Disk Model HDTH320EK3CA
|
||||
|
||||
usb:v0480pA202*
|
||||
ID_MODEL_FROM_DATABASE=Canvio Basics HDD
|
||||
|
||||
@ -9539,6 +9593,12 @@ usb:v0483p0137*
|
||||
usb:v0483p0138*
|
||||
ID_MODEL_FROM_DATABASE=Unicorn II (ST70138B + MTC-20174TQ chipset)
|
||||
|
||||
usb:v0483p0ADB*
|
||||
ID_MODEL_FROM_DATABASE=Android Debug Bridge (ADB) device
|
||||
|
||||
usb:v0483p0AFB*
|
||||
ID_MODEL_FROM_DATABASE=Android Fastboot device
|
||||
|
||||
usb:v0483p1307*
|
||||
ID_MODEL_FROM_DATABASE=Cytronix 6in1 Card Reader
|
||||
|
||||
@ -9572,6 +9632,21 @@ usb:v0483p3748*
|
||||
usb:v0483p374B*
|
||||
ID_MODEL_FROM_DATABASE=ST-LINK/V2.1
|
||||
|
||||
usb:v0483p374D*
|
||||
ID_MODEL_FROM_DATABASE=STLINK-V3 Loader
|
||||
|
||||
usb:v0483p374E*
|
||||
ID_MODEL_FROM_DATABASE=STLINK-V3
|
||||
|
||||
usb:v0483p374F*
|
||||
ID_MODEL_FROM_DATABASE=STLINK-V3
|
||||
|
||||
usb:v0483p3752*
|
||||
ID_MODEL_FROM_DATABASE=ST-LINK/V2.1
|
||||
|
||||
usb:v0483p3753*
|
||||
ID_MODEL_FROM_DATABASE=STLINK-V3
|
||||
|
||||
usb:v0483p4810*
|
||||
ID_MODEL_FROM_DATABASE=ISDN adapter
|
||||
|
||||
@ -9591,7 +9666,7 @@ usb:v0483p5720*
|
||||
ID_MODEL_FROM_DATABASE=Mass Storage Device
|
||||
|
||||
usb:v0483p5721*
|
||||
ID_MODEL_FROM_DATABASE=Hantek DDS-3X25 Arbitrary Waveform Generator
|
||||
ID_MODEL_FROM_DATABASE=Interrupt Demo
|
||||
|
||||
usb:v0483p5722*
|
||||
ID_MODEL_FROM_DATABASE=Bulk Demo
|
||||
@ -11081,6 +11156,9 @@ usb:v04A9p178A*
|
||||
usb:v04A9p178D*
|
||||
ID_MODEL_FROM_DATABASE=PIXMA MG6853
|
||||
|
||||
usb:v04A9p180B*
|
||||
ID_MODEL_FROM_DATABASE=PIXMA MG3000 series
|
||||
|
||||
usb:v04A9p1900*
|
||||
ID_MODEL_FROM_DATABASE=CanoScan LiDE 90
|
||||
|
||||
@ -11474,6 +11552,9 @@ usb:v04A9p26B4*
|
||||
usb:v04A9p26B5*
|
||||
ID_MODEL_FROM_DATABASE=MF4200 series
|
||||
|
||||
usb:v04A9p26B6*
|
||||
ID_MODEL_FROM_DATABASE=FAX-L140/L130
|
||||
|
||||
usb:v04A9p26DA*
|
||||
ID_MODEL_FROM_DATABASE=LBP3010B printer
|
||||
|
||||
@ -12395,9 +12476,18 @@ usb:v04A9p329D*
|
||||
usb:v04A9p329F*
|
||||
ID_MODEL_FROM_DATABASE=PowerShot SX530 HS
|
||||
|
||||
usb:v04A9p32A0*
|
||||
ID_MODEL_FROM_DATABASE=EOS M10
|
||||
|
||||
usb:v04A9p32A6*
|
||||
ID_MODEL_FROM_DATABASE=PowerShot SX710 HS
|
||||
|
||||
usb:v04A9p32A7*
|
||||
ID_MODEL_FROM_DATABASE=PowerShot SX610 HS
|
||||
|
||||
usb:v04A9p32A8*
|
||||
ID_MODEL_FROM_DATABASE=PowerShot G3 X
|
||||
|
||||
usb:v04A9p32AA*
|
||||
ID_MODEL_FROM_DATABASE=Powershot ELPH 160 / IXUS 160
|
||||
|
||||
@ -12431,6 +12521,21 @@ usb:v04A9p32C1*
|
||||
usb:v04A9p32C2*
|
||||
ID_MODEL_FROM_DATABASE=PowerShot SX720 HS
|
||||
|
||||
usb:v04A9p32C5*
|
||||
ID_MODEL_FROM_DATABASE=EOS M6
|
||||
|
||||
usb:v04A9p32CC*
|
||||
ID_MODEL_FROM_DATABASE=EOS 200D
|
||||
|
||||
usb:v04A9p32D1*
|
||||
ID_MODEL_FROM_DATABASE=EOS M100
|
||||
|
||||
usb:v04A9p32D2*
|
||||
ID_MODEL_FROM_DATABASE=EOS M50
|
||||
|
||||
usb:v04A9p32D4*
|
||||
ID_MODEL_FROM_DATABASE=Powershot ELPH 185 / IXUS 185 / IXY 200
|
||||
|
||||
usb:v04A9p32D5*
|
||||
ID_MODEL_FROM_DATABASE=PowerShot SX430 IS
|
||||
|
||||
@ -13811,6 +13916,9 @@ usb:v04C5p10E7*
|
||||
usb:v04C5p10FE*
|
||||
ID_MODEL_FROM_DATABASE=S500
|
||||
|
||||
usb:v04C5p1104*
|
||||
ID_MODEL_FROM_DATABASE=KD02906 Line Thermal Printer
|
||||
|
||||
usb:v04C5p1150*
|
||||
ID_MODEL_FROM_DATABASE=fi-6230
|
||||
|
||||
@ -14366,6 +14474,9 @@ usb:v04D8p900A*
|
||||
usb:v04D8p9012*
|
||||
ID_MODEL_FROM_DATABASE=PICkit4
|
||||
|
||||
usb:v04D8p9015*
|
||||
ID_MODEL_FROM_DATABASE=ICD 4 In-Circuit Debugger
|
||||
|
||||
usb:v04D8pC001*
|
||||
ID_MODEL_FROM_DATABASE=PicoLCD 20x4
|
||||
|
||||
@ -14387,6 +14498,9 @@ usb:v04D8pF437*
|
||||
usb:v04D8pF4B5*
|
||||
ID_MODEL_FROM_DATABASE=SmartScope
|
||||
|
||||
usb:v04D8pF5FE*
|
||||
ID_MODEL_FROM_DATABASE=TrueRNG
|
||||
|
||||
usb:v04D8pF8DA*
|
||||
ID_MODEL_FROM_DATABASE=Hughski Ltd. ColorHug
|
||||
|
||||
@ -14480,6 +14594,9 @@ usb:v04D9p2832*
|
||||
usb:v04D9p2834*
|
||||
ID_MODEL_FROM_DATABASE=HT82A834R Audio MCU
|
||||
|
||||
usb:v04D9p4545*
|
||||
ID_MODEL_FROM_DATABASE=Keyboard [Diatec Majestouch 2 Tenkeyless]
|
||||
|
||||
usb:v04D9pA01C*
|
||||
ID_MODEL_FROM_DATABASE=wireless multimedia keyboard with trackball [Trust ADURA 17911]
|
||||
|
||||
@ -14537,6 +14654,9 @@ usb:v04DAp0D0D*
|
||||
usb:v04DAp0D0E*
|
||||
ID_MODEL_FROM_DATABASE=DVD-ROM & CD-R/RW
|
||||
|
||||
usb:v04DAp0D14*
|
||||
ID_MODEL_FROM_DATABASE=DVD-RAM MLT08
|
||||
|
||||
usb:v04DAp0F07*
|
||||
ID_MODEL_FROM_DATABASE=KX-MB2030 Multifunction Laser Printer
|
||||
|
||||
@ -15648,10 +15768,10 @@ usb:v04E8p685E*
|
||||
ID_MODEL_FROM_DATABASE=GT-I9100 / GT-C3350 Phones (USB Debugging mode)
|
||||
|
||||
usb:v04E8p6860*
|
||||
ID_MODEL_FROM_DATABASE=Galaxy (MTP)
|
||||
ID_MODEL_FROM_DATABASE=Galaxy series, misc. (MTP mode)
|
||||
|
||||
usb:v04E8p6863*
|
||||
ID_MODEL_FROM_DATABASE=GT-I9500 [Galaxy S4] / GT-I9250 [Galaxy Nexus] (network tethering)
|
||||
ID_MODEL_FROM_DATABASE=Galaxy series, misc. (tethering mode)
|
||||
|
||||
usb:v04E8p6864*
|
||||
ID_MODEL_FROM_DATABASE=GT-I9070 (network tethering, USB debugging enabled)
|
||||
@ -16070,12 +16190,18 @@ usb:v04F2pB40E*
|
||||
usb:v04F2pB444*
|
||||
ID_MODEL_FROM_DATABASE=Lenovo Integrated Webcam
|
||||
|
||||
usb:v04F2pB563*
|
||||
ID_MODEL_FROM_DATABASE=Integrated Camera
|
||||
|
||||
usb:v04F2pB5CE*
|
||||
ID_MODEL_FROM_DATABASE=Integrated Camera
|
||||
|
||||
usb:v04F2pB5CF*
|
||||
ID_MODEL_FROM_DATABASE=Integrated IR Camera
|
||||
|
||||
usb:v04F2pB5DB*
|
||||
ID_MODEL_FROM_DATABASE=HP Webcam
|
||||
|
||||
usb:v04F3*
|
||||
ID_VENDOR_FROM_DATABASE=Elan Microelectronics Corp.
|
||||
|
||||
@ -17801,6 +17927,9 @@ usb:v04FDp0003*
|
||||
usb:v04FE*
|
||||
ID_VENDOR_FROM_DATABASE=PFU, Ltd
|
||||
|
||||
usb:v04FEp0006*
|
||||
ID_MODEL_FROM_DATABASE=Happy Hacking Keyboard Lite2
|
||||
|
||||
usb:v04FF*
|
||||
ID_VENDOR_FROM_DATABASE=E-CMOS Corp.
|
||||
|
||||
@ -18074,6 +18203,9 @@ usb:v050Dp0304*
|
||||
usb:v050Dp0307*
|
||||
ID_MODEL_FROM_DATABASE=USB 2.0 - 7 ports Hub [FSU307]
|
||||
|
||||
usb:v050Dp038C*
|
||||
ID_MODEL_FROM_DATABASE=F2CU038 HDMI Adapter
|
||||
|
||||
usb:v050Dp0409*
|
||||
ID_MODEL_FROM_DATABASE=F5U409 Serial
|
||||
|
||||
@ -19394,6 +19526,9 @@ usb:v054Cp082F*
|
||||
usb:v054Cp0847*
|
||||
ID_MODEL_FROM_DATABASE=WG-C10 Portable Wireless Server
|
||||
|
||||
usb:v054Cp0884*
|
||||
ID_MODEL_FROM_DATABASE=MDR-ZX770BN [Wireless Noise Canceling Stereo Headset]
|
||||
|
||||
usb:v054Cp088C*
|
||||
ID_MODEL_FROM_DATABASE=Portable Headphone Amplifier
|
||||
|
||||
@ -19883,9 +20018,15 @@ usb:v0566p3002*
|
||||
usb:v0566p3004*
|
||||
ID_MODEL_FROM_DATABASE=Genius KB-29E
|
||||
|
||||
usb:v0566p3027*
|
||||
ID_MODEL_FROM_DATABASE=Sun-Flex ProTouch
|
||||
|
||||
usb:v0566p3107*
|
||||
ID_MODEL_FROM_DATABASE=Keyboard
|
||||
|
||||
usb:v0566p3132*
|
||||
ID_MODEL_FROM_DATABASE=Optical mouse M-DY4DR / M-DY6DR
|
||||
|
||||
usb:v0566p4006*
|
||||
ID_MODEL_FROM_DATABASE=FID 638 Mouse (Sun Microsystems)
|
||||
|
||||
@ -20439,37 +20580,46 @@ usb:v056Ep0002*
|
||||
ID_MODEL_FROM_DATABASE=29UO Mouse
|
||||
|
||||
usb:v056Ep0057*
|
||||
ID_MODEL_FROM_DATABASE=M-PGDL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Micro Grast Pop M-PGDL
|
||||
|
||||
usb:v056Ep005C*
|
||||
ID_MODEL_FROM_DATABASE=M-PGDL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Micro Grast Pop M-PG2DL
|
||||
|
||||
usb:v056Ep005D*
|
||||
ID_MODEL_FROM_DATABASE=M-FGDL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Micro Grast Fit M-FGDL
|
||||
|
||||
usb:v056Ep005E*
|
||||
ID_MODEL_FROM_DATABASE=M-FG2DL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Micro Grast Fit M-FG2DL
|
||||
|
||||
usb:v056Ep0062*
|
||||
ID_MODEL_FROM_DATABASE=M-D18DR Mouse
|
||||
ID_MODEL_FROM_DATABASE=Optical mouse M-D18DR
|
||||
|
||||
usb:v056Ep0063*
|
||||
ID_MODEL_FROM_DATABASE=M-SODL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Laser mouse M-SODL
|
||||
|
||||
usb:v056Ep0069*
|
||||
ID_MODEL_FROM_DATABASE=M-GE1UL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Laser mouse M-GE1UL
|
||||
|
||||
usb:v056Ep0071*
|
||||
ID_MODEL_FROM_DATABASE=M-GE3DL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Laser mouse M-GE3DL
|
||||
|
||||
usb:v056Ep0072*
|
||||
ID_MODEL_FROM_DATABASE=M-LS6UL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Laser mouse M-LS6UL
|
||||
|
||||
usb:v056Ep0073*
|
||||
ID_MODEL_FROM_DATABASE=M-LS7UL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Laser mouse M-LS7UL
|
||||
|
||||
usb:v056Ep0074*
|
||||
ID_MODEL_FROM_DATABASE=M-FW1UL Mouse
|
||||
ID_MODEL_FROM_DATABASE=Optical mouse M-FW1UL
|
||||
|
||||
usb:v056Ep0075*
|
||||
ID_MODEL_FROM_DATABASE=M-FW2DL Mouse
|
||||
|
||||
usb:v056Ep2003*
|
||||
ID_MODEL_FROM_DATABASE=JC-U3613M
|
||||
|
||||
usb:v056Ep2004*
|
||||
ID_MODEL_FROM_DATABASE=JC-U3613M
|
||||
|
||||
usb:v056Ep200C*
|
||||
ID_MODEL_FROM_DATABASE=LD-USB/TX
|
||||
@ -54707,6 +54857,12 @@ usb:v1D57pAF01*
|
||||
usb:v1D5B*
|
||||
ID_VENDOR_FROM_DATABASE=Smartronix, Inc.
|
||||
|
||||
usb:v1D5C*
|
||||
ID_VENDOR_FROM_DATABASE=Fresco Logic
|
||||
|
||||
usb:v1D5Cp2000*
|
||||
ID_MODEL_FROM_DATABASE=FL2000/FL2000DX VGA/DVI/HDMI Adapter
|
||||
|
||||
usb:v1D6B*
|
||||
ID_VENDOR_FROM_DATABASE=Linux Foundation
|
||||
|
||||
@ -55097,6 +55253,9 @@ usb:v1FC9p0003*
|
||||
usb:v1FC9p010B*
|
||||
ID_MODEL_FROM_DATABASE=PR533
|
||||
|
||||
usb:v1FC9p012B*
|
||||
ID_MODEL_FROM_DATABASE=i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader
|
||||
|
||||
usb:v1FDE*
|
||||
ID_VENDOR_FROM_DATABASE=ILX Lightwave Corporation
|
||||
|
||||
@ -55808,6 +55967,63 @@ usb:v21D6*
|
||||
usb:v21D6p0002*
|
||||
ID_MODEL_FROM_DATABASE=Seismic recorder [Tellus]
|
||||
|
||||
usb:v2207*
|
||||
ID_VENDOR_FROM_DATABASE=Fuzhou Rockchip Electronics Company
|
||||
|
||||
usb:v2207p0010*
|
||||
ID_MODEL_FROM_DATABASE=GoClever Tab R83
|
||||
|
||||
usb:v2207p0011*
|
||||
ID_MODEL_FROM_DATABASE=SmartTab
|
||||
|
||||
usb:v2207p281A*
|
||||
ID_MODEL_FROM_DATABASE=RK2818 in Mask ROM mode
|
||||
|
||||
usb:v2207p290A*
|
||||
ID_MODEL_FROM_DATABASE=RK2918 in Mask ROM mode
|
||||
|
||||
usb:v2207p292A*
|
||||
ID_MODEL_FROM_DATABASE=RK2928 in Mask ROM mode
|
||||
|
||||
usb:v2207p292C*
|
||||
ID_MODEL_FROM_DATABASE=RK3026 in Mask ROM mode
|
||||
|
||||
usb:v2207p300A*
|
||||
ID_MODEL_FROM_DATABASE=RK3066 in Mask ROM mode
|
||||
|
||||
usb:v2207p300B*
|
||||
ID_MODEL_FROM_DATABASE=RK3168 in Mask ROM mode
|
||||
|
||||
usb:v2207p301A*
|
||||
ID_MODEL_FROM_DATABASE=RK3036 in Mask ROM mode
|
||||
|
||||
usb:v2207p310A*
|
||||
ID_MODEL_FROM_DATABASE=RK3066B in Mask ROM mode
|
||||
|
||||
usb:v2207p310B*
|
||||
ID_MODEL_FROM_DATABASE=RK3188 in Mask ROM mode
|
||||
|
||||
usb:v2207p310C*
|
||||
ID_MODEL_FROM_DATABASE=RK3126/RK3128 in Mask ROM mode
|
||||
|
||||
usb:v2207p310D*
|
||||
ID_MODEL_FROM_DATABASE=RK3126 in Mask ROM mode
|
||||
|
||||
usb:v2207p320A*
|
||||
ID_MODEL_FROM_DATABASE=RK3288 in Mask ROM mode
|
||||
|
||||
usb:v2207p320B*
|
||||
ID_MODEL_FROM_DATABASE=RK3228/RK3229 in Mask ROM mode
|
||||
|
||||
usb:v2207p320C*
|
||||
ID_MODEL_FROM_DATABASE=RK3328 in Mask ROM mode
|
||||
|
||||
usb:v2207p330A*
|
||||
ID_MODEL_FROM_DATABASE=RK3368 in Mask ROM mode
|
||||
|
||||
usb:v2207p330C*
|
||||
ID_MODEL_FROM_DATABASE=RK3399 in Mask ROM mode
|
||||
|
||||
usb:v2222*
|
||||
ID_VENDOR_FROM_DATABASE=MacAlly
|
||||
|
||||
@ -56462,6 +56678,15 @@ usb:v2516p0047*
|
||||
usb:v2516p9494*
|
||||
ID_MODEL_FROM_DATABASE=Sirus Headset
|
||||
|
||||
usb:v2548*
|
||||
ID_VENDOR_FROM_DATABASE=Pulse-Eight
|
||||
|
||||
usb:v2548p1001*
|
||||
ID_MODEL_FROM_DATABASE=CEC Adapter
|
||||
|
||||
usb:v2548p1002*
|
||||
ID_MODEL_FROM_DATABASE=CEC Adapter
|
||||
|
||||
usb:v2632*
|
||||
ID_VENDOR_FROM_DATABASE=TwinMOS
|
||||
|
||||
@ -56801,6 +57026,21 @@ usb:v289Bp0500*
|
||||
usb:v289Bp0502*
|
||||
ID_MODEL_FROM_DATABASE=Precision barometer
|
||||
|
||||
usb:v28DE*
|
||||
ID_VENDOR_FROM_DATABASE=Valve Software
|
||||
|
||||
usb:v28DEp1102*
|
||||
ID_MODEL_FROM_DATABASE=Wired Controller
|
||||
|
||||
usb:v28DEp1142*
|
||||
ID_MODEL_FROM_DATABASE=Wireless Steam Controller
|
||||
|
||||
usb:v28DEp2000*
|
||||
ID_MODEL_FROM_DATABASE=Lighthouse FPGA RX
|
||||
|
||||
usb:v28DEp2101*
|
||||
ID_MODEL_FROM_DATABASE=Watchman Dongle
|
||||
|
||||
usb:v2931*
|
||||
ID_VENDOR_FROM_DATABASE=Jolla Oy
|
||||
|
||||
@ -56933,6 +57173,33 @@ usb:v2A45p200C*
|
||||
usb:v2A45p2012*
|
||||
ID_MODEL_FROM_DATABASE=MX Phone (MTP & ACM)
|
||||
|
||||
usb:v2AC7*
|
||||
ID_VENDOR_FROM_DATABASE=Ultrahaptics Ltd.
|
||||
|
||||
usb:v2AC7p0101*
|
||||
ID_MODEL_FROM_DATABASE=Evaluation Kit [Dragonfly]
|
||||
|
||||
usb:v2AC7p0102*
|
||||
ID_MODEL_FROM_DATABASE=UHDK5
|
||||
|
||||
usb:v2AC7p0104*
|
||||
ID_MODEL_FROM_DATABASE=Touchbase
|
||||
|
||||
usb:v2AC7p0110*
|
||||
ID_MODEL_FROM_DATABASE=STRATOS Explore
|
||||
|
||||
usb:v2AC7p0111*
|
||||
ID_MODEL_FROM_DATABASE=STRATOS Explore DFU
|
||||
|
||||
usb:v2AC7p0112*
|
||||
ID_MODEL_FROM_DATABASE=STRATOS Inspire
|
||||
|
||||
usb:v2AC7p0113*
|
||||
ID_MODEL_FROM_DATABASE=STRATOS Inspire DFU
|
||||
|
||||
usb:v2AC7pFFFF*
|
||||
ID_MODEL_FROM_DATABASE=DFU
|
||||
|
||||
usb:v2B24*
|
||||
ID_VENDOR_FROM_DATABASE=KeepKey LLC
|
||||
|
||||
@ -56984,6 +57251,12 @@ usb:v2DCFpC952*
|
||||
usb:v2FB2*
|
||||
ID_VENDOR_FROM_DATABASE=Fujitsu, Ltd
|
||||
|
||||
usb:v3016*
|
||||
ID_VENDOR_FROM_DATABASE=Boundary Devices, LLC
|
||||
|
||||
usb:v3016p0001*
|
||||
ID_MODEL_FROM_DATABASE=Nitrogen Bootloader
|
||||
|
||||
usb:v3125*
|
||||
ID_VENDOR_FROM_DATABASE=Eagletron
|
||||
|
||||
|
||||
@ -39,11 +39,20 @@
|
||||
#
|
||||
# Sort by brand, model
|
||||
|
||||
#########################################
|
||||
# AIPTEK
|
||||
#########################################
|
||||
|
||||
# Hyperpen 12000U
|
||||
evdev:input:b0003v08CAp0010*
|
||||
EVDEV_ABS_00=::20
|
||||
EVDEV_ABS_01=::20
|
||||
|
||||
#########################################
|
||||
# Apple
|
||||
#########################################
|
||||
|
||||
# Macbook2,1 (late 2006), single-button touchpad
|
||||
# Macbook2,1 (late 2006), single-button touchpad
|
||||
evdev:input:b0003v05ACp021B*
|
||||
# Macbook4,1
|
||||
evdev:input:b0003v05ACp0229*
|
||||
@ -243,6 +252,13 @@ evdev:name:Atmel maXTouch Touch*:dmi:bvn*:bvr*:bd*:svnGOOGLE:pnSamus*
|
||||
# HP
|
||||
#########################################
|
||||
|
||||
# HP Chromebook 14 (Falco)
|
||||
evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:
|
||||
EVDEV_ABS_00=:::8
|
||||
EVDEV_ABS_01=:::8
|
||||
EVDEV_ABS_35=:::8
|
||||
EVDEV_ABS_36=:::8
|
||||
|
||||
# HP Pavilion dm4
|
||||
evdev:name:SynPS/2 Synaptics TouchPad*:dmi:*svnHewlett-Packard:pnHPPaviliondm4*
|
||||
EVDEV_ABS_00=1360:5563:47
|
||||
@ -250,6 +266,13 @@ evdev:name:SynPS/2 Synaptics TouchPad*:dmi:*svnHewlett-Packard:pnHPPaviliondm4*
|
||||
EVDEV_ABS_35=1360:5563:47
|
||||
EVDEV_ABS_36=1269:4618:61
|
||||
|
||||
# HP Pavilion g6
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnHewlett-Packard:pnHPPaviliong6*
|
||||
EVDEV_ABS_00=1284:5696:88
|
||||
EVDEV_ABS_01=1287:4838:39
|
||||
EVDEV_ABS_35=1284:5696:88
|
||||
EVDEV_ABS_36=1287:4838:39
|
||||
|
||||
# HP Pavilion dv7
|
||||
evdev:name:SynPS/2 Synaptics TouchPad*:dmi:*svnHewlett-Packard:pnHPPaviliondv7*
|
||||
EVDEV_ABS_00=1068:5805:44
|
||||
@ -265,7 +288,7 @@ evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnHP:pnHPLaptop15-bs0xx:*
|
||||
EVDEV_ABS_36=1029:4916:78
|
||||
|
||||
# HP Spectre
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:i*svnHP:pnHPSpectreNotebook*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnHP:pnHPSpectreNotebook*
|
||||
EVDEV_ABS_00=1205:5691:47
|
||||
EVDEV_ABS_01=1083:4808:65
|
||||
EVDEV_ABS_35=1205:5691:47
|
||||
@ -311,6 +334,13 @@ evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pvrThinkPad??40?:*
|
||||
EVDEV_ABS_35=::41
|
||||
EVDEV_ABS_36=::37
|
||||
|
||||
# Lenovo ThinkPad X140e
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pvrThinkPadX140e*
|
||||
EVDEV_ABS_00=1176:5767:62
|
||||
EVDEV_ABS_01=416:5534:160
|
||||
EVDEV_ABS_35=1176:5767:62
|
||||
EVDEV_ABS_36=416:5534:160
|
||||
|
||||
# Lenovo ThinkPad T430
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pvrThinkPadT430*
|
||||
EVDEV_ABS_00=1250:5631:58
|
||||
@ -417,7 +447,7 @@ evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pn*02173BG*:*pvrThinkPadEd
|
||||
#########################################
|
||||
|
||||
# Razer Blade Stealth
|
||||
evdev:name:1A586753:00 06CB:8323 Touchpad:dmi:*svnRazer:pnBladeStealth:*
|
||||
evdev:name:1A58675*:00 06CB:8323 Touchpad:dmi:*svnRazer:pnBladeStealth:*
|
||||
EVDEV_ABS_00=::12:8
|
||||
EVDEV_ABS_01=::11:8
|
||||
EVDEV_ABS_35=::12:8
|
||||
@ -475,6 +505,15 @@ evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnTOSHIBA:pnSATELLITER830*
|
||||
EVDEV_ABS_35=1238:5785:53
|
||||
EVDEV_ABS_36=1045:4826:76
|
||||
|
||||
#########################################
|
||||
# UGTablet
|
||||
#########################################
|
||||
|
||||
# Trust Flex Graphics Tablet
|
||||
evdev:input:b0003v2179p0004*
|
||||
EVDEV_ABS_00=::234
|
||||
EVDEV_ABS_01=::328
|
||||
|
||||
#########################################
|
||||
# Waltop
|
||||
#########################################
|
||||
@ -483,3 +522,8 @@ evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnTOSHIBA:pnSATELLITER830*
|
||||
evdev:input:b0003v172Fp0031*
|
||||
EVDEV_ABS_00=0:10000:400
|
||||
EVDEV_ABS_01=0:6250:400
|
||||
|
||||
#WALTOP International Corp. Graphics Tablet
|
||||
evdev:input:b0003v172Fp0047*
|
||||
EVDEV_ABS_00=0:20000:80
|
||||
EVDEV_ABS_01=0:12500:80
|
||||
|
||||
@ -62,3 +62,7 @@
|
||||
id-input:modalias:input:b0003v5543p0081*
|
||||
ID_INPUT_TABLET=1
|
||||
ID_INPUT_TABLET_PAD=1
|
||||
|
||||
# XP-PEN STAR 06
|
||||
id-input:modalias:input:b0003v28bdp0078*
|
||||
ID_INPUT_TABLET=1
|
||||
|
||||
@ -98,7 +98,8 @@
|
||||
|
||||
# common keys
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pn*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPackard*Bell*:pn*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
|
||||
KEYBOARD_KEY_86=wlan # Fn+F3 or Fn+Q for comunication key
|
||||
KEYBOARD_KEY_a5=help # Fn+F1
|
||||
@ -162,8 +163,9 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMate*C3[01]0*:pvr*
|
||||
KEYBOARD_KEY_6b=fn
|
||||
KEYBOARD_KEY_6c=screenlock # FIXME: lock tablet device/buttons
|
||||
|
||||
# Travelmate P648-G2-MG and P645-S
|
||||
# Travelmate P648-G2-MG, P648-G3-M and P645-S
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMate*P648-G2-MG*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMate*P648-G3-M*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMate*P645-S*:pvr*
|
||||
KEYBOARD_KEY_8a=f20 # Microphone mute button; should be micmute
|
||||
|
||||
@ -181,10 +183,6 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnAspire*1640:*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnAOA*:pvr*
|
||||
KEYBOARD_KEY_a9=!switchvideomode # Fn+F5
|
||||
|
||||
# Easynote models
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPackard*Bell*:pnEasynote*:pvr*
|
||||
KEYBOARD_KEY_86=wlan # Fn+F3 or Fn+Q for comunication key
|
||||
|
||||
###########################################################
|
||||
# Alienware
|
||||
###########################################################
|
||||
@ -219,6 +217,16 @@ evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*BenQ*:pn*Joybook*R22*:pvr*
|
||||
KEYBOARD_KEY_6e=wlan
|
||||
|
||||
###########################################################
|
||||
# Clevo
|
||||
###########################################################
|
||||
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnNotebook:pnW65_67SZ:pvr*
|
||||
KEYBOARD_KEY_a0=!mute
|
||||
KEYBOARD_KEY_a2=!playpause
|
||||
KEYBOARD_KEY_ae=!volumedown
|
||||
KEYBOARD_KEY_b0=!volumeup
|
||||
|
||||
###########################################################
|
||||
# Compal
|
||||
###########################################################
|
||||
@ -264,7 +272,7 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pn*
|
||||
KEYBOARD_KEY_85=brightnessdown # Fn+Down Brightness Down
|
||||
KEYBOARD_KEY_86=brightnessup # Fn+Up Brightness Up
|
||||
KEYBOARD_KEY_87=battery # Fn+F3 battery icon
|
||||
KEYBOARD_KEY_88=!wlan # Fn+(F2|PrtScr|Home) Turn On/Off Wireless
|
||||
KEYBOARD_KEY_88=unknown # Fn+F2 Turn On/Off Wireless - handled in hardware
|
||||
KEYBOARD_KEY_89=ejectclosecd # Fn+F10 Eject CD
|
||||
KEYBOARD_KEY_8a=suspend # Fn+F1 hibernate
|
||||
KEYBOARD_KEY_8b=switchvideomode # Fn+F8 CRT/LCD (high keycode: "displaytoggle")
|
||||
@ -300,6 +308,10 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnLatitude*2110:pvr*
|
||||
KEYBOARD_KEY_85=unknown # Brightness Down, also emitted by acpi-video, ignore
|
||||
KEYBOARD_KEY_86=unknown # Brightness Up, also emitted by acpi-video, ignore
|
||||
|
||||
# Dell Inspiron 537*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnInspiron537*:pvr*
|
||||
KEYBOARD_KEY_88=!wlan # Fn-PrtScr rfkill
|
||||
|
||||
# Latitude XT2
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnLatitude*XT2:pvr*
|
||||
KEYBOARD_KEY_9b=up # tablet rocker up
|
||||
@ -566,6 +578,16 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPZBook*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBook*:pvr*
|
||||
KEYBOARD_KEY_81=f20 # Fn+F8; Microphone mute button, should be micmute
|
||||
|
||||
# HP ZBook 15 G2
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPZBook15G2:pvr*
|
||||
KEYBOARD_KEY_f8=wlan # Wireless HW switch button
|
||||
|
||||
# HP ProBook 11 G1
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPProBook11G1:pvr*
|
||||
KEYBOARD_KEY_81=f20 # Fn+F8; Microphone mute button, should be micmute
|
||||
KEYBOARD_KEY_d8=f21 # touchpad toggle
|
||||
KEYBOARD_KEY_d9=f21 # touchpad toggle
|
||||
|
||||
# HP ZBook Studio G4
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnHPZBookStudioG4:pvr*
|
||||
KEYBOARD_KEY_f8=wlan # Wireless HW switch button
|
||||
@ -576,6 +598,10 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPEliteBookFolio1040G2:pvr*
|
||||
KEYBOARD_KEY_d8=!f23 # touchpad off
|
||||
KEYBOARD_KEY_d9=!f22 # touchpad on
|
||||
|
||||
# HP ProBook 650
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHP*ProBook*650*:pvr*
|
||||
KEYBOARD_KEY_f8=wlan # Wireless HW switch button
|
||||
|
||||
# HP ProBook 6555b
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard:pnHPProBook6555b:*
|
||||
KEYBOARD_KEY_b2=www # Earth
|
||||
@ -587,6 +613,11 @@ evdev:atkbd:dmi:bvn*:bvr*:svnHP*:pnHP*ProBook*640*G2*
|
||||
KEYBOARD_KEY_85=unknown # lid close; also reported via special evdev
|
||||
KEYBOARD_KEY_f8=unknown # rf kill; also reported via special evdev
|
||||
|
||||
# HP ProBook 645 G4
|
||||
evdev:atkbd:dmi:bvn*:bvr*:svnHP*:pnHP*ProBook*645*G4*
|
||||
KEYBOARD_KEY_73=slash # Slash key
|
||||
KEYBOARD_KEY_f8=wlan # Wireless HW switch button
|
||||
|
||||
###########################################################
|
||||
# IBM
|
||||
###########################################################
|
||||
@ -652,6 +683,7 @@ evdev:name:ThinkPad Extra Buttons:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
|
||||
KEYBOARD_KEY_16=mute
|
||||
KEYBOARD_KEY_17=prog1
|
||||
KEYBOARD_KEY_1a=f20 # Microphone mute button; should be micmute
|
||||
KEYBOARD_KEY_45=bookmarks
|
||||
|
||||
# ThinkPad Keyboard with TrackPoint
|
||||
evdev:input:b0003v17EFp6009*
|
||||
@ -742,9 +774,9 @@ evdev:atkbd:dmi:bvn*:bvr*:svnLENOVO*:pn*IdeaPad*Z370*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*Lenovo*V480*:pvr*
|
||||
KEYBOARD_KEY_f1=f21
|
||||
|
||||
# Lenovo Thinkcentre M800z AIO machine
|
||||
# Lenovo ThinkCentre M800z/M820z/M920z AIO machines
|
||||
# key_scancode 00 is KEY_MICMUTE
|
||||
keyboard:name:Microphone Mute Button:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
|
||||
evdev:name:Microphone Mute Button:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
|
||||
KEYBOARD_KEY_00=f20
|
||||
|
||||
# enhanced USB keyboard
|
||||
@ -903,6 +935,12 @@ evdev:input:b0003v045Ep00DB*
|
||||
KEYBOARD_KEY_c022d=up # zoomin
|
||||
KEYBOARD_KEY_c022e=down # zoomout
|
||||
|
||||
# Microsoft (Razer produced) Reclusa keyboard
|
||||
evdev:input:b0003v1532p0200*
|
||||
KEYBOARD_KEY_c01c9=shuffle
|
||||
KEYBOARD_KEY_c01ca=up # zoomin
|
||||
KEYBOARD_KEY_c01cb=down # zoomout
|
||||
|
||||
###########################################################
|
||||
# Micro Star
|
||||
###########################################################
|
||||
@ -944,6 +982,10 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*PR200*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pnU90/U100:*
|
||||
KEYBOARD_KEY_e4=reserved
|
||||
|
||||
# MSI GS65 Stealth Thin has a physical backslash key next to the space bar
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pnGS65StealthThin*:pvr*
|
||||
KEYBOARD_KEY_56=backslash
|
||||
|
||||
###########################################################
|
||||
# MSI
|
||||
###########################################################
|
||||
|
||||
@ -11,6 +11,17 @@
|
||||
# Match string formats:
|
||||
# sensor:modalias:<parent device modalias>:dmi:<dmi string>
|
||||
#
|
||||
# The device modalias can be seen in the `modalias` file
|
||||
# of the sensor parent, for example:
|
||||
# cat /sys/`udevadm info -q path -n /dev/iio:device0`/../modalias
|
||||
#
|
||||
# The full DMI string of the running machine can be read from
|
||||
# /sys/class/dmi/id/modalias
|
||||
# That requires a kernel built with CONFIG_DMIID set, which is common.
|
||||
# The full DMI string is not needed here and the meaning of individual parts
|
||||
# can be seen in the source of the DMIID kernel module
|
||||
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/dmi-id.c
|
||||
#
|
||||
# To add local entries, create a new file
|
||||
# /etc/udev/hwdb.d/61-sensor-local.hwdb
|
||||
# and add your rules there. To load the new rules execute (as root):
|
||||
@ -51,12 +62,18 @@
|
||||
#########################################
|
||||
# Acer
|
||||
#########################################
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svn*Acer*:*pn*AspireSW5-011*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svn*Acer*:*pn*AspireSW5-012*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:BMA250E*:dmi:*:svnAcer:pnIconiaW1-810:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:KIOX0009*:dmi:*:svnAcer:pnOneS1003:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Archos
|
||||
#########################################
|
||||
@ -69,12 +86,21 @@ sensor:modalias:acpi:SMO8500*:dmi:*:svnARCHOS:pnARCHOS80Cesium:*
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:*pnT100CHI*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:pnT300CHI*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:*pnT100TA*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:pnT200TA*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:*pnTP201SA*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:pn*E205SA*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svn*ASUSTeK*:*pn*TP300LA*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
@ -90,6 +116,9 @@ sensor:modalias:acpi:SMO8500*:dmi:*svn*ASUSTeK*:*pn*TP500LB*
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*svn*ASUSTeK*:*pn*TP300LD*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*svn*ASUSTeK*:*pn*TP412UA*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Axxo
|
||||
#########################################
|
||||
@ -108,7 +137,11 @@ sensor:modalias:acpi:BMA250E*:dmi:bvnINSYDECorp.:bvrCHUWI.D86JLBNR*:svnInsyde:pn
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*:svnHampoo:pnD2D3_Vi8A1:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
# Chuwi Hi8 Pro
|
||||
# Chuwi Vi10 (CWI505)
|
||||
sensor:modalias:acpi:BMA250E*:dmi:bvnINSYDECorp.:bvrG1D_S165*:svnilife:pnS165:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
# Chuwi Hi8 Pro (CWI513)
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*:svnHampoo:pnX1D3_C806N:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
@ -132,6 +165,18 @@ sensor:modalias:acpi:BOSC0200*:dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd05/07/201
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd05/28/2016:svnDefaultstring:pnDefaultstring:pvrDefaultstring:rvnHampoo:rnCherryTrailCR:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
# Chuwi CoreBook
|
||||
# Chuwi CoreBook does not have its product name filled, so we
|
||||
# match the entire dmi-alias
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:bvnAmericanMegatrendsInc.:bvrY13D_KB133.103:bd06/01/2018:svnHampoo:pnDefaultstring:pvrV100:rvnHampoo:rnY13D_KB133:rvrV100:cvnDefaultstring:ct9:cvrDefaultstring:
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Connect
|
||||
#########################################
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:svnConnect:pnTablet9:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Cube
|
||||
#########################################
|
||||
@ -152,12 +197,22 @@ sensor:modalias:acpi:KIOX000A*:dmi:*:svnCube:pni16:*
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:svnCube:pni8-L:*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
# Cube iWork 10 Flagship
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*:svnCube:pnI15-TC:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Cytrix (Mytrix)
|
||||
#########################################
|
||||
sensor:modalias:acpi:*KIOX000A*:dmi:*svn*CytrixTechnology:*pn*Complex11t*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# DEXP
|
||||
#########################################
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*svn*DEXP*:*pn*DEXPOEM*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Endless
|
||||
#########################################
|
||||
@ -179,14 +234,22 @@ sensor:modalias:acpi:KIOX000A*:dmi:bvnINSYDECorp.:bvrBYT70A.YNCHENG.WIN.007:*:sv
|
||||
#########################################
|
||||
# HP
|
||||
#########################################
|
||||
sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:*pn*HPEliteBook8540w*
|
||||
sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:*pn*HPEliteBook8560w*
|
||||
|
||||
# Laptops using the lis3lv02d device should have a first quirk applied
|
||||
# to them in the drivers/platform/x86/hp_accel.c in the kernel. The
|
||||
# quirk from "can play neverball" to "matches Windows 8 orientation"
|
||||
# is then applied below.
|
||||
sensor:modalias:platform:lis3lv02d:dmi:*svn*Hewlett-Packard*:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 0, -1; 0, 1, 0
|
||||
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:*
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*:svnHewlett-Packard:pnHPStream8Tablet:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
# HP Pavillion X2 10-n000nd
|
||||
sensor:modalias:i2c:bmc150_accel:dmi:*:svnHewlett-Packard:pnHPPavilionx2Detachable:*:rn815D:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# I.T.Works
|
||||
#########################################
|
||||
@ -247,9 +310,14 @@ sensor:modalias:acpi:BOSC0200:BOSC0200:dmi:*ThinkPadYoga11e3rdGen*
|
||||
sensor:modalias:acpi:BMA250E*:dmi:bvnLENOVO:*:pvrLenovoMIIX3-1030:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
# IdeaPad Miix 310 note this only is for BIOS version (bvr) 1HCN4?WW, which has
|
||||
# Miix3-830
|
||||
sensor:modalias:acpi:SMO8500*:dmi:bvnLENOVO:*:pvrLenovoMIIX3-830:*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
# IdeaPad Miix 310 note this only is for BIOS version (bvr) 1HCN4?WW and 1HCN2?WW, which has
|
||||
# a portrait LCD panel, versions with bvr 1HCN3?WW have a landscape panel
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:bvnLENOVO:bvr1HCN4?WW:*:svnLENOVO:pn80SG:*
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:bvnLENOVO:bvr1HCN2?WW:*:svnLENOVO:pn80SG:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
# IdeaPad Miix 320, different batches use a different sensor
|
||||
@ -257,8 +325,10 @@ sensor:modalias:acpi:*BOSC0200*:dmi:*:svnLENOVO*:pn80XF:*
|
||||
sensor:modalias:acpi:SMO8840*:dmi:*:svnLENOVO:pn80XF:pvrLenovoMIIX320*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
# IdeaPad Miix 510
|
||||
# IdeaPad Miix 510, multiple expressions match different internal names
|
||||
# pn80U1 matches IdeaPad Miix510-12ISK
|
||||
sensor:modalias:acpi:*BOSC0200*:dmi:*:svnLENOVO*:pn80XE:*
|
||||
sensor:modalias:acpi:*BOSC0200*:dmi:*:svnLENOVO*:pn80U1:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
@ -269,6 +339,10 @@ sensor:modalias:acpi:*BOSC0200*:dmi:*:svnLENOVO*:pn80XE:*
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*:svnLINX*:pnLINX1010B:*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, -1
|
||||
|
||||
# Linx 12X64
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:svnLINX*:pnLINX12X64:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# MSI
|
||||
#########################################
|
||||
@ -284,10 +358,18 @@ sensor:modalias:acpi:KIOX000A*:dmi:*:svnTMAX:pnTM800W560L:*
|
||||
#########################################
|
||||
# Onda
|
||||
#########################################
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*:svnONDA:pnV80PLUS:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:BMA250E*:dmi:bvnINSYDECorp.:bvrONDA.D89*:svnInsyde:pnONDATablet:*
|
||||
sensor:modalias:acpi:BMA250E*:dmi:bvnINSYDECorp.:bvrONDA.D86*:svnONDA:pnV820wDualOS:*
|
||||
sensor:modalias:acpi:BMA250E*:dmi:bvnINSYDECorp.:bvrONDA.W89*:svnInsyde:pnONDATablet:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
# Onda v975w, generic DMI strings, match entire dmi modalias inc. bios-date
|
||||
sensor:modalias:acpi:SMO8500*:dmi:bvnAmericanMegatrendsInc.:bvr5.6.5:bd07/25/2014:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnAMICorporation:rnAptioCRB:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Peaq
|
||||
#########################################
|
||||
@ -321,6 +403,20 @@ sensor:modalias:acpi:BMA250E*:dmi:bvnAmericanMegatrendsInc.:bvr3BAIR1013:bd08/22
|
||||
sensor:modalias:acpi:BMA250E*:dmi:bvnAmericanMegatrendsInc.:bvr3BAIR1014:bd10/24/2014:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnAMICorporation:rnAptioCRB:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
# Point of View TAB-P1005W-232 (v2.0)
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:rvnPOV:rnI102A:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
# Point of View TAB-P1006W-232-3G (v1.0)
|
||||
sensor:modalias:i2c:bmc150_accel:dmi:bvnINSYDECorp.:*:svnInsyde:pnBayTrail:*:rvn105B:rn0E57:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Prowise
|
||||
#########################################
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*:svnProwise:pnPT301:*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Teclast
|
||||
#########################################
|
||||
@ -330,6 +426,14 @@ sensor:modalias:acpi:KIOX000A*:dmi:*:svnTECLAST:pnX80Pro:*
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:svnTECLAST:pnX98PlusII:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
# Teclast X98 Plus I (A5C6), generic DMI strings, match entire dmi modalias inc. bios-date
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.011:bd11/03/2015:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnAMICorporation:rnCherryTrailCR:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
# Teclast F5
|
||||
sensor:modalias:acpi:KIOX010A*:dmi:*:svnTECLAST:pnF5:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Trekstor
|
||||
#########################################
|
||||
@ -337,6 +441,15 @@ sensor:modalias:acpi:BMA250*:dmi:*:bvrTREK.G.WI71C.JGBMRBA*:*:svnInsyde:pnST7041
|
||||
sensor:modalias:acpi:BMA250*:dmi:*:bvrTREK.G.WI71C.JGBMRBA*:*:svnTrekStor:pnSurfTabwintron7.0ST70416-6:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
|
||||
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:svnTREKSTOR:pnPrimetabT13B:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Umax
|
||||
#########################################
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*:svnUMAX:pnVisionBook10WiPlus:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Yours
|
||||
#########################################
|
||||
|
||||
@ -96,7 +96,7 @@
|
||||
# The list may contain a single item which must be marked with an
|
||||
# asterisk.
|
||||
#
|
||||
# Local changes to the a non-default resolution of the mouse (e.g. through
|
||||
# Local changes to the non-default resolution of the mouse (e.g. through
|
||||
# third-party software) must not be entered into this file, use a local
|
||||
# hwdb instead.
|
||||
#
|
||||
@ -280,6 +280,14 @@ mouse:usb:v03f0p0641:name:PixArt HP X1200 USB Optical Mouse:
|
||||
mouse:usb:v04b3p3107:name:*
|
||||
MOUSE_DPI=800@125
|
||||
|
||||
##########################################
|
||||
# Kensington
|
||||
##########################################
|
||||
|
||||
# Kensington Expert Mouse trackball
|
||||
mouse:usb:v047dp1020:*Kensington Expert Mouse*
|
||||
ID_INPUT_TRACKBALL=1
|
||||
|
||||
##########################################
|
||||
# Lenovo
|
||||
##########################################
|
||||
@ -292,9 +300,9 @@ mouse:usb:v17efp6019:name:Lenovo Optical USB Mouse:
|
||||
mouse:usb:v17efp6019:name:Logitech Lenovo USB Optical Mouse:
|
||||
MOUSE_DPI=1000@166
|
||||
|
||||
# ThinkPad USB Laser Mouse
|
||||
mouse:usb:v17efp6044:name:ThinkPad USB Laser Mouse:
|
||||
MOUSE_DPI=1200@125
|
||||
# Lenovo USB mouse model MO28UOL
|
||||
mouse:usb:v04b3p310c:name:USB Optical Mouse:
|
||||
MOUSE_DPI=400@142
|
||||
|
||||
# Lenovo Precision USB Mouse
|
||||
mouse:usb:v17efp6050:name:Lenovo Precision USB Mouse:
|
||||
@ -306,6 +314,9 @@ mouse:usb:v17efp601d:name:Primax Lenovo Laser Mouse:
|
||||
mouse:usb:v17efp6045:name:Lenovo USB Laser Mouse:
|
||||
MOUSE_DPI=1600@125
|
||||
|
||||
# ThinkPad USB Laser Mouse
|
||||
mouse:usb:v17efp6044:name:ThinkPad USB Laser Mouse:
|
||||
MOUSE_DPI=1200@125
|
||||
|
||||
##########################################
|
||||
# Logitech
|
||||
@ -316,11 +327,143 @@ mouse:usb:v17efp6045:name:Lenovo USB Laser Mouse:
|
||||
# model name. The usb vid/pid is the same for all those devices.
|
||||
# Until 3.19 is available, this list just has the Wireless PID entry.
|
||||
|
||||
## G Series ##
|
||||
|
||||
# Logitech G5 Laser Mouse
|
||||
mouse:usb:v046dpc049:name:Logitech USB Gaming Mouse:
|
||||
# Logitech G500s Laser Gaming Mouse
|
||||
mouse:usb:v046dpc24e:name:Logitech G500s Laser Gaming Mouse:
|
||||
MOUSE_DPI=400@500 *800@500 2000@500
|
||||
|
||||
# Logitech G9
|
||||
mouse:usb:v046dpc048:name:Logitech G9 Laser Mouse:
|
||||
MOUSE_DPI=400@1000 800@1000 *1600@1000
|
||||
|
||||
# Logitech G9x [Call of Duty MW3 Edition]
|
||||
mouse:usb:v046dpc249:name:Logitech G9x Laser Mouse:
|
||||
MOUSE_DPI=400@1000 800@1000 *1600@1000 3200@1000
|
||||
|
||||
# Logitech G100s Optical Gaming Mouse
|
||||
mouse:usb:v046dpc247:name:Logitech G100s Optical Gaming Mouse:
|
||||
MOUSE_DPI=*1000@500 1750@500 2500@500
|
||||
|
||||
# Logitech G400 (Wired)
|
||||
mouse:usb:v046dpc245:name:Logitech Gaming Mouse G400:
|
||||
MOUSE_DPI=400@1000 *800@1000 1800@1000 3600@1000
|
||||
|
||||
# Logitech G400s (Wired)
|
||||
mouse:usb:v046dpc24c:name:Logitech G400s Optical Gaming Mouse:
|
||||
MOUSE_DPI=400@1000 *800@1000 2000@1000 4000@1000
|
||||
|
||||
# Logitech G402 Hyperion Fury
|
||||
mouse:usb:v046dpc07e:name:Logitech Gaming Mouse G402:
|
||||
MOUSE_DPI=400@1000 *800@1000 1600@1000 3200@1000
|
||||
|
||||
# Logitech G500 Mouse
|
||||
mouse:usb:v046dpc068:name:Logitech G500:
|
||||
MOUSE_DPI=*1600@500 2600@500 3600@500
|
||||
|
||||
# Logitech G502 Proteus Spectrum
|
||||
mouse:usb:v046dpc332:name:Logitech Gaming Mouse G502:
|
||||
MOUSE_DPI=1200@1000 *2400@1000 3200@1000 6400@1000
|
||||
|
||||
# Logitech G700 Laser Mouse (Wired)
|
||||
mouse:usb:v046dpc06b:name:Logitech G700 Laser Mouse:
|
||||
# Logitech G700 Laser Mouse (Wireless)
|
||||
mouse:usb:v046dpc531:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=*1000@500 3800@500 500@1000 1500@1000 2000@1000
|
||||
|
||||
# Logitech G703 (Wired)
|
||||
mouse:usb:v046dpc087:name:Logitech G703 Wired/Wireless Gaming Mouse:
|
||||
# Logitech G703 (Wireless)
|
||||
mouse:usb:v046dpc539:name:Logitech USB Receiver Mouse:
|
||||
MOUSE_DPI=400@1000 800@1000 *1600@1000 3200@1000
|
||||
|
||||
## M Series ##
|
||||
|
||||
# Logitech Wireless Mouse M185
|
||||
mouse:usb:v046dp4008:name:Logitech M185:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:4008:
|
||||
# Logitech Wireless Mouse M510
|
||||
mouse:usb:v046dp1025:name:Logitech M510:
|
||||
# Logitech M705 (marathon mouse)
|
||||
mouse:usb:v046dp101b:name:Logitech M705:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:101b:
|
||||
MOUSE_DPI=1000@125
|
||||
|
||||
# Logitech M305 Wireless Optical Mouse
|
||||
mouse:usb:v046dpc52f:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=1000@170
|
||||
|
||||
# Logitech Wireless Mouse M310
|
||||
mouse:usb:v046dp1024:name:Logitech M310:
|
||||
MOUSE_DPI=1100@168
|
||||
|
||||
# Logitech Wireless Mouse M325
|
||||
mouse:usb:v046dp400a:name:Logitech M325:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:400a:
|
||||
MOUSE_DPI=600@166
|
||||
MOUSE_WHEEL_CLICK_ANGLE=20
|
||||
|
||||
# Logitech M570 trackball
|
||||
mouse:usb:v046dp1028:name:Logitech M570:
|
||||
MOUSE_DPI=540@167
|
||||
ID_INPUT_TRACKBALL=1
|
||||
|
||||
## MX Series ##
|
||||
|
||||
# Logitech Performance MX
|
||||
mouse:usb:v046dp101a:name:Logitech Performance MX:
|
||||
MOUSE_DPI=1000@166
|
||||
|
||||
# Logitech MX Revolution
|
||||
mouse:usb:v046dpc51a:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=800@200
|
||||
|
||||
# Logitech MX 518
|
||||
mouse:usb:v046dpc01e:name:Logitech USB-PS/2 Optical Mouse:
|
||||
MOUSE_DPI=400@125 *800@125 1600@125
|
||||
|
||||
# Logitech MX1000 Laser Cordless Mouse
|
||||
mouse:bluetooth:v046dpb003:name:Logitech MX1000 mouse:
|
||||
MOUSE_DPI=800@80
|
||||
|
||||
# Logitech Anywhere MX
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:1017:
|
||||
mouse:usb:v046dp1017:name:Logitech Anywhere MX:
|
||||
# Logitech Anywhere MX 2S
|
||||
mouse:usb:v046dp406a:name:Logitech MX Anywhere 2S:
|
||||
MOUSE_WHEEL_CLICK_ANGLE=20
|
||||
|
||||
# Logitech MX Master
|
||||
# Horiz wheel has 14 stops, angle is rounded up
|
||||
mouse:usb:v046dp4041:name:Logitech MX Master:
|
||||
MOUSE_DPI=1000@166
|
||||
MOUSE_WHEEL_CLICK_ANGLE=15
|
||||
MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
|
||||
MOUSE_WHEEL_CLICK_COUNT=24
|
||||
MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14
|
||||
|
||||
# Logitech MX Master 2S (via Logitech Unifying Receiver)
|
||||
# Horiz wheel has 14 stops, angle is rounded up
|
||||
mouse:usb:v046dp4069:name:Logitech MX Master 2s:
|
||||
MOUSE_DPI=1000@125
|
||||
MOUSE_WHEEL_CLICK_ANGLE=15
|
||||
MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
|
||||
MOUSE_WHEEL_CLICK_COUNT=24
|
||||
MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14
|
||||
|
||||
# Logitech MX Master 2S (via Bluetooth)
|
||||
# Horiz wheel has 14 stops, angle is rounded up
|
||||
mouse:bluetooth:v046dpb019:name:MX Master 2S Mouse:
|
||||
MOUSE_DPI=2000@2000
|
||||
MOUSE_WHEEL_CLICK_ANGLE=15
|
||||
MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
|
||||
MOUSE_WHEEL_CLICK_COUNT=24
|
||||
MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14
|
||||
|
||||
## Other ##
|
||||
|
||||
# Logitech M-BJ58 Optical Mouse
|
||||
mouse:usb:v046dpc00e:name:Logitech USB-PS/2 Optical Mouse:
|
||||
# Logitech Mini Optical Mouse
|
||||
@ -337,25 +480,10 @@ mouse:usb:v046dpc401:name:Logitech USB-PS/2 Trackball:
|
||||
mouse:usb:v046dpc501:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=800@63
|
||||
|
||||
# Lenovo USB mouse model MO28UOL
|
||||
mouse:usb:v04b3p310c:name:USB Optical Mouse:
|
||||
MOUSE_DPI=400@142
|
||||
|
||||
# Logitech M570 trackball
|
||||
mouse:usb:v046dp1028:name:Logitech M570:
|
||||
MOUSE_DPI=540@167
|
||||
ID_INPUT_TRACKBALL=1
|
||||
|
||||
# Logitech USB-PS/2 M-BZ96C
|
||||
mouse:usb:v046dpc045:name:Logitech USB-PS/2 Optical Mouse:
|
||||
MOUSE_DPI=600@125
|
||||
|
||||
# Logitech Wireless Mouse M325
|
||||
mouse:usb:v046dp400a:name:Logitech M325:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:400a:
|
||||
MOUSE_DPI=600@166
|
||||
MOUSE_WHEEL_CLICK_ANGLE=20
|
||||
|
||||
# Logitech MX400 Performance Laser Mouse
|
||||
mouse:usb:v046dpc043:name:Logitech USB-PS/2 Optical Mouse:
|
||||
# Logitech MX1000 Laser Cordless Mouse
|
||||
@ -366,58 +494,10 @@ mouse:usb:v046dpc50e:name:Logitech USB Receiver:
|
||||
mouse:usb:v046dpc040:name:Logitech USB-PS/2 Optical Mouse:
|
||||
MOUSE_DPI=800@125
|
||||
|
||||
# Logitech MX 518
|
||||
mouse:usb:v046dpc01e:name:Logitech USB-PS/2 Optical Mouse:
|
||||
MOUSE_DPI=400@125 *800@125 1600@125
|
||||
|
||||
# Logitech, Inc. RX 250 Optical Mouse
|
||||
mouse:usb:v046dpc050:name:Logitech USB-PS/2 Optical Mouse:
|
||||
MOUSE_DPI=1000@142
|
||||
|
||||
# Logitech Wireless Mouse M185
|
||||
mouse:usb:v046dp4008:name:Logitech M185:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:4008:
|
||||
# Logitech Wireless Mouse M510
|
||||
mouse:usb:v046dp1025:name:Logitech M510:
|
||||
# Logitech M705 (marathon mouse)
|
||||
mouse:usb:v046dp101b:name:Logitech M705:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:101b:
|
||||
MOUSE_DPI=1000@125
|
||||
|
||||
# Logitech MX Revolution
|
||||
mouse:usb:v046dpc51a:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=800@200
|
||||
|
||||
# Logitech G5 Laser Mouse
|
||||
mouse:usb:v046dpc049:name:Logitech USB Gaming Mouse:
|
||||
# Logitech G500s Laser Gaming Mouse
|
||||
mouse:usb:v046dpc24e:name:Logitech G500s Laser Gaming Mouse:
|
||||
MOUSE_DPI=400@500 *800@500 2000@500
|
||||
|
||||
# Logitech G9
|
||||
mouse:usb:v046dpc048:name:Logitech G9 Laser Mouse:
|
||||
MOUSE_DPI=400@1000 800@1000 *1600@1000
|
||||
|
||||
# Logitech G9x [Call of Duty MW3 Edition]
|
||||
mouse:usb:v046dpc249:name:Logitech G9x Laser Mouse:
|
||||
MOUSE_DPI=400@1000 800@1000 *1600@1000 3200@1000
|
||||
|
||||
# Logitech G400 (Wired)
|
||||
mouse:usb:v046dpc245:name:Logitech Gaming Mouse G400:
|
||||
MOUSE_DPI=400@1000 *800@1000 1800@1000 3600@1000
|
||||
|
||||
# Logitech G400s (Wired)
|
||||
mouse:usb:v046dpc24c:name:Logitech G400s Optical Gaming Mouse:
|
||||
MOUSE_DPI=400@1000 *800@1000 2000@1000 4000@1000
|
||||
|
||||
# Logitech G402 Hyperion Fury
|
||||
mouse:usb:v046dpc07e:name:Logitech Gaming Mouse G402:
|
||||
MOUSE_DPI=400@1000 *800@1000 1600@1000 3200@1000
|
||||
|
||||
# Logitech G502 Proteus Spectrum
|
||||
mouse:usb:v046dpc332:name:Logitech Gaming Mouse G502:
|
||||
MOUSE_DPI=1200@1000 *2400@1000 3200@1000 6400@1000
|
||||
|
||||
# Logitech B605 Wireless Mouse (also M505)
|
||||
mouse:usb:v046dp101d:name:Logitech B605:
|
||||
mouse:usb:v046dp101d:name:Logitech M505:
|
||||
@ -443,50 +523,10 @@ mouse:usb:v046dp402d:name:Logitech M560:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:402d:
|
||||
MOUSE_DPI=1000@125
|
||||
|
||||
# Logitech M305 Wireless Optical Mouse
|
||||
mouse:usb:v046dpc52f:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=1000@170
|
||||
|
||||
# Logitech Performance MX
|
||||
mouse:usb:v046dp101a:name:Logitech Performance MX:
|
||||
MOUSE_DPI=1000@166
|
||||
|
||||
# Logitech MX Master
|
||||
# Horiz wheel has 14 stops, angle is rounded up
|
||||
mouse:usb:v046dp4041:name:Logitech MX Master:
|
||||
MOUSE_DPI=1000@166
|
||||
MOUSE_WHEEL_CLICK_ANGLE=15
|
||||
MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
|
||||
MOUSE_WHEEL_CLICK_COUNT=24
|
||||
MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14
|
||||
|
||||
# Logitech MX Master 2s
|
||||
# Horiz wheel has 14 stops, angle is rounded up
|
||||
mouse:usb:v046dp4069:name:Logitech MX Master 2s:
|
||||
MOUSE_DPI=1000@125
|
||||
MOUSE_WHEEL_CLICK_ANGLE=15
|
||||
MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
|
||||
MOUSE_WHEEL_CLICK_COUNT=24
|
||||
MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14
|
||||
|
||||
# Logitech MK260 Wireless Combo Receiver aka M-R0011
|
||||
mouse:usb:v046dpc52e:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=1000@200
|
||||
|
||||
# Logitech G100s Optical Gaming Mouse
|
||||
mouse:usb:v046dpc247:name:Logitech G100s Optical Gaming Mouse:
|
||||
MOUSE_DPI=*1000@500 1750@500 2500@500
|
||||
|
||||
# Logitech G700 Laser Mouse (Wired)
|
||||
mouse:usb:v046dpc06b:name:Logitech G700 Laser Mouse:
|
||||
# Logitech G700 Laser Mouse (Wireless)
|
||||
mouse:usb:v046dpc531:name:Logitech USB Receiver:
|
||||
MOUSE_DPI=*1000@500 3800@500 500@1000 1500@1000 2000@1000
|
||||
|
||||
# Logitech Wireless Mouse M310
|
||||
mouse:usb:v046dp1024:name:Logitech M310:
|
||||
MOUSE_DPI=1100@168
|
||||
|
||||
# Logitech USB Laser Mouse M-UAS144 [LS1 Laser Mouse]
|
||||
mouse:usb:v046dpc062:name:Logitech USB Laser Mouse:
|
||||
MOUSE_DPI=1200@125
|
||||
@ -501,18 +541,10 @@ mouse:usb:v046dp4026:name:Logitech T400:
|
||||
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:4026:
|
||||
MOUSE_DPI=1300@166
|
||||
|
||||
# Logitech G500 Mouse
|
||||
mouse:usb:v046dpc068:name:Logitech G500:
|
||||
MOUSE_DPI=*1600@500 2600@500 3600@500
|
||||
|
||||
# Logitech TrackMan Wheel (USB)
|
||||
mouse:usb:v046dpc404:name:Logitech Trackball:
|
||||
MOUSE_DPI=300@125
|
||||
|
||||
# Logitech MX1000 Laser Cordless Mouse
|
||||
mouse:bluetooth:v046dpb003:name:Logitech MX1000 mouse:
|
||||
MOUSE_DPI=800@80
|
||||
|
||||
# Logitech Ultrathin Touch Mouse
|
||||
mouse:bluetooth:v046dpb00d:name:Ultrathin Touch Mouse:
|
||||
MOUSE_DPI=1000@1000
|
||||
@ -569,6 +601,10 @@ mouse:bluetooth:v045ep07f3:name:Arc Touch Mouse SE:
|
||||
mouse:bluetooth:v0000p0000:name:Surface Mouse:
|
||||
MOUSE_DPI=2000@2000
|
||||
|
||||
# Microsoft Classic IntelliMouse
|
||||
mouse:usb:v045ep0823:name:Microsoft Microsoft?? Classic IntelliMouse??:
|
||||
MOUSE_DPI=3200@1000
|
||||
|
||||
##########################################
|
||||
# Mionix
|
||||
##########################################
|
||||
|
||||
@ -43,7 +43,7 @@
|
||||
# udevadm info /dev/input/eventXX.
|
||||
#
|
||||
# Allowed properties are:
|
||||
# POINTINGSTICK_CONST_ACCEL
|
||||
# POINTINGSTICK_CONST_ACCEL (deprecated)
|
||||
# POINTINGSTICK_SENSITIVITY
|
||||
#
|
||||
# Entries should be sorted with growing _SENSITIVITY and _CONST_ACCEL.
|
||||
@ -52,6 +52,11 @@
|
||||
# POINTINGSTICK_CONST_ACCEL #
|
||||
#########################################
|
||||
#
|
||||
# DO NOT USE THIS PROPERTY. This property is kept for backwards
|
||||
# compatibility. The only known consumer, libinput, stopped reading this
|
||||
# property in version 1.9.0. No new entries for this property should be
|
||||
# added.
|
||||
#
|
||||
# Trackpoint const accel settings are specified as
|
||||
# POINTINGSTICK_CONST_ACCEL=<accel>
|
||||
#
|
||||
@ -104,6 +109,8 @@ evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE7470*:pvr*
|
||||
|
||||
# Lenovo Thinkpad X220
|
||||
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX220:*
|
||||
# Lenovo Thinkpad X220 tablet
|
||||
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX220Tablet:*
|
||||
# Lenovo Thinkpad X230
|
||||
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX230:*
|
||||
# Lenovo Thinkpad X230 tablet
|
||||
@ -129,12 +136,13 @@ evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX1Ta
|
||||
POINTINGSTICK_SENSITIVITY=200
|
||||
POINTINGSTICK_CONST_ACCEL=1.0
|
||||
|
||||
# Lenovo Thinkpad X200/X201/X200s/X201s
|
||||
# Lenovo Thinkpad X200/X201/X200s/X201s/X200 Tablet/X201 Tablet
|
||||
# Note these come with 2 revisions of keyboard, with the trackpoints having a
|
||||
# different sensitivity in the different revisions. 1.25 is a bit slow for the
|
||||
# least sensitive revision, but it is better to be a bit slow than too fast.
|
||||
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX20?:*
|
||||
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX20??:*
|
||||
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX20?Tablet:*
|
||||
POINTINGSTICK_SENSITIVITY=200
|
||||
POINTINGSTICK_CONST_ACCEL=1.25
|
||||
|
||||
|
||||
@ -86,6 +86,12 @@
|
||||
<tr class="even"><td>Insyde Software</td><td>INSY</td><td>11/10/2017</td> </tr>
|
||||
<tr class="odd"><td>Nexstgo Company Limited</td><td>NXGO</td><td>11/13/2017</td> </tr>
|
||||
<tr class="even"><td>Ampere Computing</td><td>AMPC</td><td>03/29/2018</td> </tr>
|
||||
<tr class="odd"><td>IDEMIA</td><td>IDEM</td><td>06/26/2018</td> </tr>
|
||||
<tr class="even"><td>Vishay Intertechnology, Inc.</td><td>VSHY</td><td>07/09/2018</td> </tr>
|
||||
<tr class="odd"><td>DMIST RESEARCH LTD</td><td>DMST</td><td>07/09/2018</td> </tr>
|
||||
<tr class="even"><td>COMHEAR, INC.</td><td>CMHR</td><td>08/02/2018</td> </tr>
|
||||
<tr class="odd"><td>Sensel, Inc.</td><td>SNSL</td><td>08/20/2018</td> </tr>
|
||||
<tr class="even"><td>G2touch Co., LTD</td><td>GTCH</td><td>12/04/2018</td> </tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</body>
|
||||
|
||||
@ -17,7 +17,6 @@ TAB = White('\t', exact=1).suppress()
|
||||
COMMENTLINE = pythonStyleComment + EOL
|
||||
EMPTYLINE = LineEnd()
|
||||
text_eol = lambda name: Regex(r'[^\n]+')(name) + EOL
|
||||
# text_eol = lambda name: Word(printables + ' ' + '®üäßçõãİó ײ⁶´‐“\u200E\u200B')(name) + EOL
|
||||
|
||||
def klass_grammar():
|
||||
klass_line = Literal('C ').suppress() + NUM2('klass') + text_eol('text')
|
||||
|
||||
9016
hwdb/ma-large.txt
9016
hwdb/ma-large.txt
File diff suppressed because it is too large
Load Diff
2025
hwdb/ma-medium.txt
2025
hwdb/ma-medium.txt
File diff suppressed because it is too large
Load Diff
2012
hwdb/ma-small.txt
2012
hwdb/ma-small.txt
File diff suppressed because it is too large
Load Diff
@ -36,9 +36,11 @@ endif
|
||||
############################################################
|
||||
|
||||
parse_hwdb_py = find_program('parse_hwdb.py')
|
||||
test('parse-hwdb',
|
||||
parse_hwdb_py,
|
||||
timeout : 90)
|
||||
if want_tests != 'false'
|
||||
test('parse-hwdb',
|
||||
parse_hwdb_py,
|
||||
timeout : 90)
|
||||
endif
|
||||
|
||||
############################################################
|
||||
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- Mode: python; coding: utf-8; indent-tabs-mode: nil -*- */
|
||||
# SPDX-License-Identifier: MIT
|
||||
# SPDX-License-Identifier: MIT
|
||||
#
|
||||
# This file is distributed under the MIT license, see below.
|
||||
#
|
||||
@ -30,8 +29,7 @@ import sys
|
||||
import os
|
||||
|
||||
try:
|
||||
from pyparsing import (Word, White, Literal, ParserElement, Regex,
|
||||
LineStart, LineEnd,
|
||||
from pyparsing import (Word, White, Literal, ParserElement, Regex, LineEnd,
|
||||
OneOrMore, Combine, Or, Optional, Suppress, Group,
|
||||
nums, alphanums, printables,
|
||||
stringEnd, pythonStyleComment, QuotedString,
|
||||
|
||||
1060
hwdb/pci.ids
1060
hwdb/pci.ids
File diff suppressed because it is too large
Load Diff
@ -2258,7 +2258,7 @@
|
||||
<tr class="even"><td>Wildfire Communications Inc</td><td>WLD</td><td>02/13/1997</td> </tr>
|
||||
<tr class="odd"><td>WillNet Inc.</td><td>WNI</td><td>04/19/2000</td> </tr>
|
||||
<tr class="even"><td>Winbond Electronics Corporation</td><td>WEC</td><td>11/29/1996</td> </tr>
|
||||
<tr class="odd"><td>Wincor Nixdorf International GmbH</td><td>WNX</td><td>09/20/2004</td> </tr>
|
||||
<tr class="odd"><td>Diebold Nixdorf Systems GmbH</td><td>WNX</td><td>09/20/2004</td> </tr>
|
||||
<tr class="even"><td>Winmate Communication Inc</td><td>WMT</td><td>03/15/2001</td> </tr>
|
||||
<tr class="odd"><td>Winnov L.P.</td><td>WNV</td><td>03/07/1997</td> </tr>
|
||||
<tr class="even"><td>WiNRADiO Communications</td><td>WRC</td><td>09/11/1997</td> </tr>
|
||||
@ -2303,7 +2303,7 @@
|
||||
<tr class="odd"><td>Z3 Technology</td><td>ZTT</td><td>12/14/2010</td> </tr>
|
||||
<tr class="even"><td>Zalman Tech Co., Ltd.</td><td>ZMT</td><td>05/07/2007</td> </tr>
|
||||
<tr class="odd"><td>Zandar Technologies plc</td><td>ZAN</td><td>12/03/2003</td> </tr>
|
||||
<tr class="even"><td>Zazzle Technologies</td><td>ZAZ</td><td>01/18/2008</td> </tr>
|
||||
<tr class="even"><td>ZeeVee, Inc.</td><td>ZAZ</td><td>01/18/2008</td> </tr>
|
||||
<tr class="odd"><td>Zebra Technologies International, LLC</td><td>ZBR</td><td>09/15/2003</td> </tr>
|
||||
<tr class="even"><td>Zefiro Acoustics</td><td>ZAX</td><td>11/29/1996</td> </tr>
|
||||
<tr class="odd"><td>ZeitControl cardsystems GmbH</td><td>ZCT</td><td>01/20/1999</td> </tr>
|
||||
@ -2434,6 +2434,14 @@
|
||||
<tr class="even"><td>Varjo Technologies</td><td>VRT</td><td>11/17/2017</td> </tr>
|
||||
<tr class="odd"><td>Japan E.M.Solutions Co., Ltd.</td><td>JEM</td><td>05/24/2018</td> </tr>
|
||||
<tr class="even"><td>QD Laser, Inc.</td><td>QDL</td><td>05/31/2018</td> </tr>
|
||||
<tr class="odd"><td>VADATECH INC</td><td>VAT</td><td>07/09/2018</td> </tr>
|
||||
<tr class="even"><td>Medicaroid Corporation</td><td>MCJ</td><td>08/20/2018</td> </tr>
|
||||
<tr class="odd"><td>Razer Taiwan Co. Ltd.</td><td>RZR</td><td>08/20/2018</td> </tr>
|
||||
<tr class="even"><td>GIGA-BYTE TECHNOLOGY CO., LTD.</td><td>GBT</td><td>09/05/2018</td> </tr>
|
||||
<tr class="odd"><td>Kontron GmbH</td><td>KOM</td><td>09/05/2018</td> </tr>
|
||||
<tr class="even"><td>Convergent Engineering, Inc.</td><td>CIE</td><td>09/05/2018</td> </tr>
|
||||
<tr class="odd"><td>WyreStorm Technologies LLC </td><td>WYR</td><td>09/05/2018</td> </tr>
|
||||
<tr class="even"><td>Astro HQ LLC</td><td>AHQ </td><td>09/05/2018</td> </tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</body>
|
||||
|
||||
123
hwdb/usb.ids
123
hwdb/usb.ids
@ -9,8 +9,8 @@
|
||||
# The latest version can be obtained from
|
||||
# http://www.linux-usb.org/usb.ids
|
||||
#
|
||||
# Version: 2018.05.04
|
||||
# Date: 2018-05-04 20:34:07
|
||||
# Version: 2018.12.04
|
||||
# Date: 2018-12-04 20:34:05
|
||||
#
|
||||
|
||||
# Vendors, devices and interfaces. Please keep sorted.
|
||||
@ -783,6 +783,7 @@
|
||||
8370 7 Port Hub
|
||||
8371 PS/2 Keyboard And Mouse
|
||||
8372 FT8U100AX Serial Port
|
||||
87d0 Cressi Dive Computer Interface
|
||||
8a28 Rainforest Automation ZigBee Controller
|
||||
8a98 TIAO Multi-Protocol Adapter
|
||||
8b28 Alpermann+Velte TCI70
|
||||
@ -815,6 +816,7 @@
|
||||
bcd8 Stellaris Development Board
|
||||
bcd9 Stellaris Evaluation Board
|
||||
bcda Stellaris ICDI Board
|
||||
bd90 PICAXE Download Cable [AXE027]
|
||||
bdc8 Egnite GmbH - JTAG/RS-232 adapter
|
||||
bfd8 OpenDCC
|
||||
bfd9 OpenDCC (Sniffer)
|
||||
@ -1191,6 +1193,7 @@
|
||||
00da WLI-U2-KG54L 802.11bg [ZyDAS ZD1211B]
|
||||
00db External Hard Drive HD-PF32OU2 [Buffalo Ministation]
|
||||
00e8 WLI-UC-G300N Wireless LAN Adapter [Ralink RT2870]
|
||||
00f9 Portable DVD Writer (DVSM-PL58U2)
|
||||
0105 External Hard Drive HD-CEU2 [Drive Station]
|
||||
012c SATA Bridge
|
||||
012e WLI-UC-AG300N Wireless LAN Adapter
|
||||
@ -1204,11 +1207,14 @@
|
||||
019e WLI-UC-GNP Wireless LAN Adapter
|
||||
01a1 MiniStation Metro
|
||||
01a2 WLI-UC-GNM Wireless LAN Adapter [Ralink RT8070]
|
||||
01ba SATA Bridge
|
||||
01dc Ultra-Slim Portable DVD Writer (DVSM-PC58U2V)
|
||||
01de External Hard Drive HD-PCTU3 [Buffalo MiniStation]
|
||||
01ea SATA Bridge
|
||||
01ee WLI-UC-GNM2 Wireless LAN Adapter [Ralink RT3070]
|
||||
01f1 SATA Adapter [HD-LBU3]
|
||||
01fd WLI-UC-G450 Wireless LAN Adapter
|
||||
027e HD-LCU3
|
||||
0412 Award Software International
|
||||
0413 Leadtek Research, Inc.
|
||||
1310 WinFast TV - NTSC + FM
|
||||
@ -1318,6 +1324,7 @@
|
||||
3121 WoW tap chat
|
||||
3220 Sound Blaster Tactic(3D) Sigma sound card
|
||||
3232 Sound Blaster Premium HD [SBX]
|
||||
3237 SB X-Fi Surround 5.1 Pro
|
||||
3f00 E-Mu Xboard 25 MIDI Controller
|
||||
3f02 E-Mu 0202
|
||||
3f04 E-Mu 0404
|
||||
@ -1937,6 +1944,7 @@
|
||||
8140 TUSB8041 4-Port Hub
|
||||
8142 TUSB8041 4-Port Hub
|
||||
926b TUSB9260 Boot Loader
|
||||
bef3 CC1352R1 Launchpad
|
||||
dbc0 Device Bay Controller
|
||||
e001 GraphLink [SilverLink]
|
||||
e003 TI-84 Plus Calculator
|
||||
@ -2382,6 +2390,7 @@
|
||||
0797 Optical Mouse 200
|
||||
0799 Surface Pro embedded keyboard
|
||||
07a5 Wireless Receiver 1461C
|
||||
07b2 2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900
|
||||
07b9 Wired Keyboard 200
|
||||
07c6 RTL8153 GigE [Surface Dock Ethernet]
|
||||
07ca Surface Pro 3 Docking Station Audio Device
|
||||
@ -2397,6 +2406,7 @@
|
||||
090b Hub
|
||||
090c SD Card
|
||||
091a Hub
|
||||
09c0 Surface Type Cover
|
||||
0a00 Lumia 950 Dual SIM (RM-1118)
|
||||
930a ISOUSB.SYS Intel 82930 Isochronous IO Test Board
|
||||
ffca Catalina
|
||||
@ -2464,6 +2474,8 @@
|
||||
4d62 HP Laser Mobile Mini Mouse
|
||||
4d75 Rocketfish RF-FLBTAD Bluetooth Adapter
|
||||
4d81 Dell N889 Optical Mouse
|
||||
4d91 Laser mouse M-D16DL
|
||||
4d92 Optical mouse M-D17DR
|
||||
4de3 HP 5-Button Optical Comfort Mouse
|
||||
4de7 webcam
|
||||
4e04 Lenovo Keyboard KB1021
|
||||
@ -2525,6 +2537,7 @@
|
||||
080f Webcam C120
|
||||
0810 QuickCam Pro
|
||||
0819 Webcam C210
|
||||
081a Webcam C260
|
||||
081b Webcam C310
|
||||
081d HD Webcam C510
|
||||
0820 QuickCam VC
|
||||
@ -2728,6 +2741,7 @@
|
||||
c07d G502 Mouse
|
||||
c07e G402 Gaming Mouse
|
||||
c083 G403 Prodigy Gaming Mouse
|
||||
c084 G203 Gaming Mouse
|
||||
c101 UltraX Media Remote
|
||||
c110 Harmony 785/880/885 Remote
|
||||
c111 Harmony 525 Remote
|
||||
@ -2824,9 +2838,11 @@
|
||||
c31c Keyboard K120
|
||||
c31d Media Keyboard K200
|
||||
c31f Comfort Keyboard K290
|
||||
c326 Washable Keyboard K310
|
||||
c328 Corded Keyboard K280e
|
||||
c332 G502 Proteus Spectrum Optical Mouse
|
||||
c335 G910 Orion Spectrum Mechanical Keyboard
|
||||
c33a G413 Gaming Keyboard
|
||||
c401 TrackMan Marble Wheel
|
||||
c402 Marble Mouse (2-button)
|
||||
c403 Turbo TrackMan Marble FX
|
||||
@ -3158,6 +3174,7 @@
|
||||
4254 BUA-100 Bluetooth Adapter
|
||||
ac01 Savi 7xx
|
||||
ad01 GameCom 777 5.1 Headset
|
||||
af01 DA80
|
||||
c008 Audio 655 DSP
|
||||
c00e Blackwire C310 headset
|
||||
0480 Toshiba America Inc
|
||||
@ -3172,6 +3189,7 @@
|
||||
a009 Stor.E Basics
|
||||
a00d STOR.E BASICS 500GB
|
||||
a100 Canvio Alu 2TB 2.5" Black External Disk Model HDTH320EK3CA
|
||||
a102 Canvio Alu 2TB 2.5" Black External Disk Model HDTH320EK3CA
|
||||
a202 Canvio Basics HDD
|
||||
a208 Canvio Basics 2TB USB 3.0 Portable Hard Drive
|
||||
b001 Stor.E Partner
|
||||
@ -3199,6 +3217,8 @@
|
||||
0483 STMicroelectronics
|
||||
0137 BeWAN ADSL USB ST (blue or green)
|
||||
0138 Unicorn II (ST70138B + MTC-20174TQ chipset)
|
||||
0adb Android Debug Bridge (ADB) device
|
||||
0afb Android Fastboot device
|
||||
1307 Cytronix 6in1 Card Reader
|
||||
163d Cool Icam Digi-MP3
|
||||
2015 TouchChip® Fingerprint Reader
|
||||
@ -3210,13 +3230,18 @@
|
||||
3747 ST Micro Connect Lite
|
||||
3748 ST-LINK/V2
|
||||
374b ST-LINK/V2.1
|
||||
374d STLINK-V3 Loader
|
||||
374e STLINK-V3
|
||||
374f STLINK-V3
|
||||
3752 ST-LINK/V2.1
|
||||
3753 STLINK-V3
|
||||
4810 ISDN adapter
|
||||
481d BT Digital Access adapter
|
||||
5000 ST Micro/Ergenic ERG BT-002 Bluetooth Adapter
|
||||
5001 ST Micro Bluetooth Device
|
||||
5710 Joystick in FS Mode
|
||||
5720 Mass Storage Device
|
||||
5721 Hantek DDS-3X25 Arbitrary Waveform Generator
|
||||
5721 Interrupt Demo
|
||||
5722 Bulk Demo
|
||||
5730 Audio Speaker
|
||||
5731 Microphone
|
||||
@ -3713,6 +3738,7 @@
|
||||
1787 PIXMA MX490 Series
|
||||
178a PIXMA MG3600 Series
|
||||
178d PIXMA MG6853
|
||||
180b PIXMA MG3000 series
|
||||
1900 CanoScan LiDE 90
|
||||
1901 CanoScan 8800F
|
||||
1904 CanoScan LiDE 100
|
||||
@ -3844,6 +3870,7 @@
|
||||
26b0 MF4600 series
|
||||
26b4 MF4010 series
|
||||
26b5 MF4200 series
|
||||
26b6 FAX-L140/L130
|
||||
26da LBP3010B printer
|
||||
26e6 iR1024
|
||||
271a LBP6000
|
||||
@ -4151,7 +4178,10 @@
|
||||
329c PowerShot SX400 IS
|
||||
329d PowerShot G7 X
|
||||
329f PowerShot SX530 HS
|
||||
32a0 EOS M10
|
||||
32a6 PowerShot SX710 HS
|
||||
32a7 PowerShot SX610 HS
|
||||
32a8 PowerShot G3 X
|
||||
32aa Powershot ELPH 160 / IXUS 160
|
||||
32ab PowerShot ELPH 350HS / IXUS 275 HS
|
||||
32ac PowerShot ELPH 170 IS / IXUS 170
|
||||
@ -4163,6 +4193,11 @@
|
||||
32bf PowerShot SX420 IS
|
||||
32c1 PowerShot ELPH 180 / IXUS 175
|
||||
32c2 PowerShot SX720 HS
|
||||
32c5 EOS M6
|
||||
32cc EOS 200D
|
||||
32d1 EOS M100
|
||||
32d2 EOS M50
|
||||
32d4 Powershot ELPH 185 / IXUS 185 / IXY 200
|
||||
32d5 PowerShot SX430 IS
|
||||
32db SELPHY CP1300
|
||||
04aa DaeWoo Telecom, Ltd
|
||||
@ -4623,6 +4658,7 @@
|
||||
10e1 fi-5220C
|
||||
10e7 fi-5900C
|
||||
10fe S500
|
||||
1104 KD02906 Line Thermal Printer
|
||||
1150 fi-6230
|
||||
125a PalmSecure Sensor Device - MP
|
||||
200f Sigma DP2 (Mass Storage)
|
||||
@ -4808,6 +4844,7 @@
|
||||
9004 Microchip REAL ICE
|
||||
900a PICkit3
|
||||
9012 PICkit4
|
||||
9015 ICD 4 In-Circuit Debugger
|
||||
c001 PicoLCD 20x4
|
||||
e11c TL866CS EEPROM Programmer [MiniPRO]
|
||||
f2c4 Macareux-labs Hygrometry Temperature Sensor
|
||||
@ -4815,6 +4852,7 @@
|
||||
f3aa Macareux-labs Usbce Bootloader mode
|
||||
f437 SBE Tech Ultrasonic Anemometer
|
||||
f4b5 SmartScope
|
||||
f5fe TrueRNG
|
||||
f8da Hughski Ltd. ColorHug
|
||||
f8e8 Harmony 300/350 Remote
|
||||
f91c SPROG IIv3
|
||||
@ -4846,6 +4884,7 @@
|
||||
2519 Shenzhen LogoTech 2.4GHz receiver
|
||||
2832 HT82A832R Audio MCU
|
||||
2834 HT82A834R Audio MCU
|
||||
4545 Keyboard [Diatec Majestouch 2 Tenkeyless]
|
||||
a01c wireless multimedia keyboard with trackball [Trust ADURA 17911]
|
||||
a050 Chatman V1
|
||||
a052 USB-zyTemp
|
||||
@ -4865,6 +4904,7 @@
|
||||
0d0a CD-R Drive KXL-CB20AN
|
||||
0d0d CDRCB03
|
||||
0d0e DVD-ROM & CD-R/RW
|
||||
0d14 DVD-RAM MLT08
|
||||
0f07 KX-MB2030 Multifunction Laser Printer
|
||||
0f40 Printer
|
||||
104d Elite Panaboard UB-T880 (HID)
|
||||
@ -5235,8 +5275,8 @@
|
||||
685c GT-I9250 Phone [Galaxy Nexus] (Mass storage mode)
|
||||
685d GT-I9100 Phone [Galaxy S II] (Download mode)
|
||||
685e GT-I9100 / GT-C3350 Phones (USB Debugging mode)
|
||||
6860 Galaxy (MTP)
|
||||
6863 GT-I9500 [Galaxy S4] / GT-I9250 [Galaxy Nexus] (network tethering)
|
||||
6860 Galaxy series, misc. (MTP mode)
|
||||
6863 Galaxy series, misc. (tethering mode)
|
||||
6864 GT-I9070 (network tethering, USB debugging enabled)
|
||||
6865 Galaxy (PTP mode)
|
||||
6866 Galaxy (debugging mode)
|
||||
@ -5376,8 +5416,10 @@
|
||||
b3fd HD WebCam (Asus N-series)
|
||||
b40e HP Truevision HD camera
|
||||
b444 Lenovo Integrated Webcam
|
||||
b563 Integrated Camera
|
||||
b5ce Integrated Camera
|
||||
b5cf Integrated IR Camera
|
||||
b5db HP Webcam
|
||||
04f3 Elan Microelectronics Corp.
|
||||
000a Touchscreen
|
||||
0103 ActiveJet K-2024 Multimedia Keyboard
|
||||
@ -5953,6 +5995,7 @@
|
||||
04fd Soliton Systems, K.K.
|
||||
0003 Smart Card Reader II
|
||||
04fe PFU, Ltd
|
||||
0006 Happy Hacking Keyboard Lite2
|
||||
04ff E-CMOS Corp.
|
||||
0500 Siam United Hi-Tech
|
||||
0001 DART Keyboard Mouse
|
||||
@ -6044,6 +6087,7 @@
|
||||
0257 F5U257 Serial
|
||||
0304 FSU304 USB 2.0 - 4 Ports Hub
|
||||
0307 USB 2.0 - 7 ports Hub [FSU307]
|
||||
038c F2CU038 HDMI Adapter
|
||||
0409 F5U409 Serial
|
||||
0416 Staples 12416 7 port desktop hub
|
||||
0551 F6C550-AVR UPS
|
||||
@ -6484,6 +6528,7 @@
|
||||
07c4 ILCE-6000 (aka Alpha-6000) in Mass Storage mode
|
||||
082f Walkman NWZW Series
|
||||
0847 WG-C10 Portable Wireless Server
|
||||
0884 MDR-ZX770BN [Wireless Noise Canceling Stereo Headset]
|
||||
088c Portable Headphone Amplifier
|
||||
08b7 ILCE-6000 (aka Alpha-6000) in MTP mode
|
||||
094e ILCE-6000 (aka Alpha-6000) in PC Remote mode
|
||||
@ -6647,7 +6692,9 @@
|
||||
2802 Kbd Hub
|
||||
3002 Keyboard
|
||||
3004 Genius KB-29E
|
||||
3027 Sun-Flex ProTouch
|
||||
3107 Keyboard
|
||||
3132 Optical mouse M-DY4DR / M-DY6DR
|
||||
4006 FID 638 Mouse (Sun Microsystems)
|
||||
0567 Xyratex International, Ltd
|
||||
0568 Quartz Ingenierie
|
||||
@ -6832,17 +6879,20 @@
|
||||
0003 Device Bay Controller
|
||||
056e Elecom Co., Ltd
|
||||
0002 29UO Mouse
|
||||
0057 M-PGDL Mouse
|
||||
005c M-PGDL Mouse
|
||||
005d M-FGDL Mouse
|
||||
005e M-FG2DL Mouse
|
||||
0062 M-D18DR Mouse
|
||||
0063 M-SODL Mouse
|
||||
0069 M-GE1UL Mouse
|
||||
0071 M-GE3DL Mouse
|
||||
0072 M-LS6UL Mouse
|
||||
0073 M-LS7UL Mouse
|
||||
0074 M-FW1UL Mouse
|
||||
0057 Micro Grast Pop M-PGDL
|
||||
005c Micro Grast Pop M-PG2DL
|
||||
005d Micro Grast Fit M-FGDL
|
||||
005e Micro Grast Fit M-FG2DL
|
||||
0062 Optical mouse M-D18DR
|
||||
0063 Laser mouse M-SODL
|
||||
0069 Laser mouse M-GE1UL
|
||||
0071 Laser mouse M-GE3DL
|
||||
0072 Laser mouse M-LS6UL
|
||||
0073 Laser mouse M-LS7UL
|
||||
0074 Optical mouse M-FW1UL
|
||||
0075 M-FW2DL Mouse
|
||||
2003 JC-U3613M
|
||||
2004 JC-U3613M
|
||||
200c LD-USB/TX
|
||||
4002 Laneed 100Mbps Ethernet LD-USB/TX [pegasus]
|
||||
4005 LD-USBL/TX
|
||||
@ -18256,6 +18306,8 @@
|
||||
ad02 SE340D PC Remote Control
|
||||
af01 AUVIO Universal Remote Receiver for PlayStation 3
|
||||
1d5b Smartronix, Inc.
|
||||
1d5c Fresco Logic
|
||||
2000 FL2000/FL2000DX VGA/DVI/HDMI Adapter
|
||||
1d6b Linux Foundation
|
||||
0001 1.1 root hub
|
||||
0002 2.0 root hub
|
||||
@ -18386,6 +18438,7 @@
|
||||
1fc9 NXP Semiconductors
|
||||
0003 LPC1343
|
||||
010b PR533
|
||||
012b i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader
|
||||
1fde ILX Lightwave Corporation
|
||||
0001 UART Bridge
|
||||
1fe7 Vertex Wireless Co., Ltd.
|
||||
@ -18623,6 +18676,25 @@
|
||||
0001 EPOC Consumer Headset Wireless Dongle
|
||||
21d6 Agecodagis SARL
|
||||
0002 Seismic recorder [Tellus]
|
||||
2207 Fuzhou Rockchip Electronics Company
|
||||
0010 GoClever Tab R83
|
||||
0011 SmartTab
|
||||
281a RK2818 in Mask ROM mode
|
||||
290a RK2918 in Mask ROM mode
|
||||
292a RK2928 in Mask ROM mode
|
||||
292c RK3026 in Mask ROM mode
|
||||
300a RK3066 in Mask ROM mode
|
||||
300b RK3168 in Mask ROM mode
|
||||
301a RK3036 in Mask ROM mode
|
||||
310a RK3066B in Mask ROM mode
|
||||
310b RK3188 in Mask ROM mode
|
||||
310c RK3126/RK3128 in Mask ROM mode
|
||||
310d RK3126 in Mask ROM mode
|
||||
320a RK3288 in Mask ROM mode
|
||||
320b RK3228/RK3229 in Mask ROM mode
|
||||
320c RK3328 in Mask ROM mode
|
||||
330a RK3368 in Mask ROM mode
|
||||
330c RK3399 in Mask ROM mode
|
||||
2222 MacAlly
|
||||
0004 iWebKey Keyboard
|
||||
2520 Mini Tablet
|
||||
@ -18841,6 +18913,9 @@
|
||||
002d Alcor mouse
|
||||
0047 MasterKeys Pro L
|
||||
9494 Sirus Headset
|
||||
2548 Pulse-Eight
|
||||
1001 CEC Adapter
|
||||
1002 CEC Adapter
|
||||
2632 TwinMOS
|
||||
3209 7-in-1 Card Reader
|
||||
2639 Xsens
|
||||
@ -18954,6 +19029,11 @@
|
||||
0100 Dual-relay board
|
||||
0500 Energy meter
|
||||
0502 Precision barometer
|
||||
28de Valve Software
|
||||
1102 Wired Controller
|
||||
1142 Wireless Steam Controller
|
||||
2000 Lighthouse FPGA RX
|
||||
2101 Watchman Dongle
|
||||
2931 Jolla Oy
|
||||
0a01 Jolla Phone MTP
|
||||
0a02 Jolla Phone Developer
|
||||
@ -18998,6 +19078,15 @@
|
||||
200b MX Phone (PTP)
|
||||
200c MX Phone (PTP & ADB)
|
||||
2012 MX Phone (MTP & ACM)
|
||||
2ac7 Ultrahaptics Ltd.
|
||||
0101 Evaluation Kit [Dragonfly]
|
||||
0102 UHDK5
|
||||
0104 Touchbase
|
||||
0110 STRATOS Explore
|
||||
0111 STRATOS Explore DFU
|
||||
0112 STRATOS Inspire
|
||||
0113 STRATOS Inspire DFU
|
||||
ffff DFU
|
||||
2b24 KeepKey LLC
|
||||
0001 Bitcoin hardware wallet
|
||||
2c02 Planex Communications
|
||||
@ -19015,6 +19104,8 @@
|
||||
2dcf Dialog Semiconductor
|
||||
c952 Audio Class 2.0 Devices
|
||||
2fb2 Fujitsu, Ltd
|
||||
3016 Boundary Devices, LLC
|
||||
0001 Nitrogen Bootloader
|
||||
3125 Eagletron
|
||||
0001 TrackerPod Camera Stand
|
||||
3136 Navini Networks
|
||||
|
||||
@ -1,8 +1,5 @@
|
||||
; special .c mode with reduced indentation for man pages
|
||||
((nil . ((indent-tabs-mode . nil)
|
||||
(tab-width . 8)
|
||||
(fill-column . 79)))
|
||||
(c-mode . ((fill-column . 80)
|
||||
((c-mode . ((fill-column . 80)
|
||||
(c-basic-offset . 2)
|
||||
(eval . (c-set-offset 'substatement-open 0))
|
||||
(eval . (c-set-offset 'statement-case-open 0))
|
||||
@ -10,5 +7,8 @@
|
||||
(eval . (c-set-offset 'arglist-intro '++))
|
||||
(eval . (c-set-offset 'arglist-close 0))))
|
||||
(nxml-mode . ((nxml-child-indent . 2)
|
||||
(fill-column . 119)))
|
||||
(meson-mode . ((meson-indent-basic . 8))))
|
||||
(fill-column . 109)))
|
||||
(meson-mode . ((meson-indent-basic . 8)))
|
||||
(nil . ((indent-tabs-mode . nil)
|
||||
(tab-width . 8)
|
||||
(fill-column . 79))))
|
||||
|
||||
@ -34,10 +34,10 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para><command>bootctl</command> can check the EFI boot loader status, list
|
||||
available entries, and install, update, or remove the
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
boot loader on the current system.</para>
|
||||
<para><command>bootctl</command> can check the EFI boot loader status, list available boot loaders and boot loader
|
||||
entries, and install, update, or remove the
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> boot loader on the
|
||||
current system.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -45,8 +45,6 @@
|
||||
<para>The following options are understood:</para>
|
||||
|
||||
<variablelist>
|
||||
<xi:include href="standard-options.xml" xpointer="help" />
|
||||
<xi:include href="standard-options.xml" xpointer="version" />
|
||||
<varlistentry>
|
||||
<term><option>--path=</option></term>
|
||||
<listitem><para>Path to the EFI System Partition (ESP). If not specified, <filename>/efi</filename>,
|
||||
@ -64,8 +62,12 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--no-variables</option></term>
|
||||
<listitem><para>Do not touch the EFI boot variables.</para></listitem>
|
||||
<listitem><para>Do not touch the firmware's boot loader list stored in EFI variables.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<xi:include href="standard-options.xml" xpointer="no-pager"/>
|
||||
<xi:include href="standard-options.xml" xpointer="help"/>
|
||||
<xi:include href="standard-options.xml" xpointer="version"/>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
@ -76,42 +78,54 @@
|
||||
<varlistentry>
|
||||
<term><option>status</option></term>
|
||||
|
||||
<listitem><para>Shows the currently installed versions of the boot loader binaries and all current
|
||||
EFI boot variables. If no command is specified, this is the implied default.</para></listitem>
|
||||
<listitem><para>Shows brief information about the system firmware, the boot loader that was used to boot the
|
||||
system, the boot loaders currently available in the ESP, the boot loaders listed in the firmware's list of boot
|
||||
loaders and the current default boot loader entry. If no command is specified, this is the implied
|
||||
default.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>list</option></term>
|
||||
<term><option>install</option></term>
|
||||
|
||||
<listitem><para>Shows all configured boot loader entries.</para></listitem>
|
||||
<listitem><para>Installs systemd-boot into the EFI system partition. A copy of <command>systemd-boot</command>
|
||||
will be stored as the EFI default/fallback loader at
|
||||
<filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. The boot loader is then added to the
|
||||
top of the firmware's boot loader list.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>update</option></term>
|
||||
|
||||
<listitem><para>Updates all installed versions of
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
||||
if the current version is newer than the version installed in the EFI system
|
||||
partition. This also includes the EFI default/fallback loader at
|
||||
<filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. A
|
||||
systemd-boot entry in the EFI boot variables is created if there is no current
|
||||
entry. The created entry will be added to the end of the boot order list.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>install</option></term>
|
||||
|
||||
<listitem><para>Installs systemd-boot into the EFI system partition. A copy of systemd-boot will
|
||||
be stored as the EFI default/fallback loader at
|
||||
<filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. A systemd-boot entry in
|
||||
the EFI boot variables is created and added to the top of the boot order list.</para></listitem>
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, if the
|
||||
available version is newer than the version installed in the EFI system partition. This also includes the EFI
|
||||
default/fallback loader at <filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. The boot
|
||||
loader is then added to end of the firmware's boot loader list if missing.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>remove</option></term>
|
||||
|
||||
<listitem><para>Removes all installed versions of systemd-boot from the EFI system partition,
|
||||
and removes systemd-boot from the EFI boot variables.</para></listitem>
|
||||
<listitem><para>Removes all installed versions of <command>systemd-boot</command> from the EFI system partition
|
||||
and the firmware's boot loader list.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>list</option></term>
|
||||
|
||||
<listitem><para>Shows all available boot loader entries implementing the <ulink
|
||||
url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader
|
||||
Specification</ulink>, as well as any other entries discovered or automatically generated by the boot
|
||||
loader.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>set-default</option> <replaceable>ID</replaceable></term>
|
||||
<term><option>set-oneshot</option> <replaceable>ID</replaceable></term>
|
||||
|
||||
<listitem><para>Sets the default boot loader entry. Takes a single boot loader entry ID string as argument. The
|
||||
<option>set-oneshot</option> command will set the default entry only for the next boot, the
|
||||
<option>set-default</option> will set it persistently for all future boots.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
@ -122,12 +136,19 @@
|
||||
<para>On success, 0 is returned, a non-zero failure code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Environment</title>
|
||||
<para>If <varname>$SYSTEMD_RELAX_ESP_CHECKS=1</varname> is set the validation checks for the ESP are relaxed, and
|
||||
the path specified with <option>--path=</option> may refer to any kind of file system on any kind of
|
||||
partition.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
<para>
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
||||
<ulink url="https://github.com/systemd/systemd/blob/master/doc/BOOT_LOADER_SPECIFICATION.md">Boot Loader Specification</ulink>,
|
||||
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface">Boot Loader Interface</ulink>
|
||||
<ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>,
|
||||
<ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>
|
||||
</para>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||
|
||||
@ -143,6 +143,28 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--json=</option><replaceable>MODE</replaceable></term>
|
||||
|
||||
<listitem>
|
||||
<para>When used with the <command>call</command> or <command>get-property</command> command, shows output
|
||||
formatted as JSON. Expects one of <literal>short</literal> (for the shortest possible output without any
|
||||
redundant whitespace or line breaks) or <literal>pretty</literal> (for a pretty version of the same, with
|
||||
indentation and line breaks). Note that transformation from D-Bus marshalling to JSON is done in a loss-less
|
||||
way, which means type information is embedded into the JSON object tree.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-j</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>Equivalent to <option>--json=pretty</option> when invoked interactively from a terminal. Otherwise
|
||||
equivalent to <option>--json=short</option>, in particular when the output is piped to some other
|
||||
program.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--expect-reply=</option><replaceable>BOOL</replaceable></term>
|
||||
|
||||
@ -269,8 +291,9 @@
|
||||
<listitem><para>Dump messages being exchanged. If
|
||||
<replaceable>SERVICE</replaceable> is specified, show messages
|
||||
to or from this peer, identified by its well-known or unique
|
||||
name. Otherwise, show all messages on the bus. Use Ctrl-C to
|
||||
terminate the dump.</para></listitem>
|
||||
name. Otherwise, show all messages on the bus. Use
|
||||
<keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>
|
||||
to terminate the dump.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||
|
||||
|
||||
@ -210,7 +210,8 @@
|
||||
<varlistentry>
|
||||
<term><command>info</command></term>
|
||||
|
||||
<listitem><para>Show detailed information about core dumps
|
||||
<listitem><para>Show detailed information about the last core dump
|
||||
or core dumps matching specified characteristics
|
||||
captured in the journal.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -250,6 +250,15 @@
|
||||
option.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>sector-size=</option></term>
|
||||
|
||||
<listitem><para>Specifies the sector size in bytes. See
|
||||
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
for possible values and the default value of this
|
||||
option.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>swap</option></term>
|
||||
|
||||
|
||||
@ -593,7 +593,7 @@ AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])</p
|
||||
<citerefentry project='die-net'><refentrytitle>automake</refentrytitle><manvolnum>1</manvolnum></citerefentry>-based
|
||||
projects:</para>
|
||||
|
||||
<programlisting>DISTCHECK_CONFIGURE_FLAGS = \
|
||||
<programlisting>AM_DISTCHECK_CONFIGURE_FLAGS = \
|
||||
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)</programlisting>
|
||||
|
||||
<para>Finally, unit files should be installed in the system with an automake excerpt like the following:</para>
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||
|
||||
|
||||
11
man/id128-app-specific.c
Normal file
11
man/id128-app-specific.c
Normal file
@ -0,0 +1,11 @@
|
||||
#include <stdio.h>
|
||||
#include <systemd/sd-id128.h>
|
||||
|
||||
#define OUR_APPLICATION_ID SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97)
|
||||
|
||||
int main(int argc, char *argv[]) {
|
||||
sd_id128_t id;
|
||||
sd_id128_get_machine_app_specific(OUR_APPLICATION_ID, &id);
|
||||
printf("Our application ID: " SD_ID128_FORMAT_STR "\n", SD_ID128_FORMAT_VAL(id));
|
||||
return 0;
|
||||
}
|
||||
25
man/journal-iterate-unique.c
Normal file
25
man/journal-iterate-unique.c
Normal file
@ -0,0 +1,25 @@
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
#include <systemd/sd-journal.h>
|
||||
|
||||
int main(int argc, char *argv[]) {
|
||||
sd_journal *j;
|
||||
const void *d;
|
||||
size_t l;
|
||||
int r;
|
||||
|
||||
r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY);
|
||||
if (r < 0) {
|
||||
fprintf(stderr, "Failed to open journal: %s\n", strerror(-r));
|
||||
return 1;
|
||||
}
|
||||
r = sd_journal_query_unique(j, "_SYSTEMD_UNIT");
|
||||
if (r < 0) {
|
||||
fprintf(stderr, "Failed to query journal: %s\n", strerror(-r));
|
||||
return 1;
|
||||
}
|
||||
SD_JOURNAL_FOREACH_UNIQUE(j, d, l)
|
||||
printf("%.*s\n", (int) l, (const char*) d);
|
||||
sd_journal_close(j);
|
||||
return 0;
|
||||
}
|
||||
@ -148,9 +148,9 @@
|
||||
<term><option>-a</option></term>
|
||||
<term><option>--all</option></term>
|
||||
|
||||
<listitem><para>Show all fields in full, even if they
|
||||
include unprintable characters or are very
|
||||
long.</para></listitem>
|
||||
<listitem><para>Show all fields in full, even if they include unprintable characters or are very long. By
|
||||
default, fields with unprintable characters are abbreviated as "blob data". (Note that the pager may escape
|
||||
unprintable characters again.)</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -316,10 +316,23 @@
|
||||
<option>json</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>formats entries as JSON data structures, one per
|
||||
line (see
|
||||
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/json">Journal JSON Format</ulink>
|
||||
for more information).</para>
|
||||
<para>formats entries as JSON objects, separated by newline characters (see <ulink
|
||||
url="https://www.freedesktop.org/wiki/Software/systemd/json">Journal JSON Format</ulink> for more
|
||||
information). Field values are generally encoded as JSON strings, with three exceptions:
|
||||
<orderedlist>
|
||||
<listitem><para>Fields larger than 4096 bytes are encoded as <constant>null</constant> values. (This
|
||||
may be turned off by passing <option>--all</option>, but be aware that this may allocate overly long
|
||||
JSON objects.) </para></listitem>
|
||||
|
||||
<listitem><para>Journal entries permit non-unique fields within the same log entry. JSON does not allow
|
||||
non-unique fields within objects. Due to this, if a non-unique field is encountered a JSON array is
|
||||
used as field value, listing all field values as elements.</para></listitem>
|
||||
|
||||
<listitem><para>Fields containing non-printable or non-UTF8 bytes are encoded as arrays containing
|
||||
the raw bytes individually formatted as unsigned numbers.</para></listitem>
|
||||
</orderedlist>
|
||||
|
||||
Note that this encoding is reversible (with the exception of the size limit).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -346,6 +359,19 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>
|
||||
<option>json-seq</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>formats entries as JSON data structures, but prefixes them with an ASCII Record Separator
|
||||
character (0x1E) and suffixes them with an ASCII Line Feed character (0x0A), in accordance with <ulink
|
||||
url="https://tools.ietf.org/html/rfc7464">JavaScript Object Notation (JSON) Text Sequences </ulink>
|
||||
(<literal>application/json-seq</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>
|
||||
<option>cat</option>
|
||||
@ -375,14 +401,11 @@
|
||||
<varlistentry>
|
||||
<term><option>--output-fields=</option></term>
|
||||
|
||||
<listitem><para>A comma separated list of the fields which should
|
||||
be included in the output. This only has an effect for the output modes
|
||||
which would normally show all fields (<option>verbose</option>,
|
||||
<option>export</option>, <option>json</option>,
|
||||
<option>json-pretty</option>, and <option>json-sse</option>). The
|
||||
<literal>__CURSOR</literal>, <literal>__REALTIME_TIMESTAMP</literal>,
|
||||
<literal>__MONOTONIC_TIMESTAMP</literal>, and
|
||||
<literal>_BOOT_ID</literal> fields are always
|
||||
<listitem><para>A comma separated list of the fields which should be included in the output. This only has an
|
||||
effect for the output modes which would normally show all fields (<option>verbose</option>,
|
||||
<option>export</option>, <option>json</option>, <option>json-pretty</option>, <option>json-sse</option> and
|
||||
<option>json-seq</option>). The <literal>__CURSOR</literal>, <literal>__REALTIME_TIMESTAMP</literal>,
|
||||
<literal>__MONOTONIC_TIMESTAMP</literal>, and <literal>_BOOT_ID</literal> fields are always
|
||||
printed.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -705,18 +728,6 @@
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--new-id128</option></term>
|
||||
|
||||
<listitem><para>Instead of showing journal contents, generate
|
||||
a new 128-bit ID suitable for identifying messages. This is
|
||||
intended for usage by developers who need a new identifier for
|
||||
a new message they introduce and want to make
|
||||
recognizable. This will print the new ID in four different
|
||||
formats which can be copied into source code or similar.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--header</option></term>
|
||||
|
||||
@ -738,32 +749,28 @@
|
||||
<term><option>--vacuum-time=</option></term>
|
||||
<term><option>--vacuum-files=</option></term>
|
||||
|
||||
<listitem><para>Removes the oldest archived journal files until the disk
|
||||
space they use falls below the specified size (specified with
|
||||
the usual <literal>K</literal>, <literal>M</literal>,
|
||||
<literal>G</literal> and <literal>T</literal> suffixes), or all
|
||||
archived journal files contain no data older than the specified
|
||||
timespan (specified with the usual <literal>s</literal>,
|
||||
<literal>m</literal>, <literal>h</literal>,
|
||||
<literal>days</literal>, <literal>months</literal>,
|
||||
<literal>weeks</literal> and <literal>years</literal> suffixes),
|
||||
or no more than the specified number of separate journal files
|
||||
remain. Note that running <option>--vacuum-size=</option> has
|
||||
only an indirect effect on the output shown by
|
||||
<option>--disk-usage</option>, as the latter includes active
|
||||
journal files, while the vacuuming operation only operates
|
||||
on archived journal files. Similarly,
|
||||
<option>--vacuum-files=</option> might not actually reduce the
|
||||
number of journal files to below the specified number, as it
|
||||
will not remove active journal
|
||||
files. <option>--vacuum-size=</option>,
|
||||
<option>--vacuum-time=</option> and
|
||||
<option>--vacuum-files=</option> may be combined in a single
|
||||
invocation to enforce any combination of a size, a time and a
|
||||
number of files limit on the archived journal
|
||||
files. Specifying any of these three parameters as zero is
|
||||
equivalent to not enforcing the specific limit, and is thus
|
||||
redundant.</para></listitem>
|
||||
<listitem><para>Removes the oldest archived journal files until the disk space they use falls below the
|
||||
specified size (specified with the usual <literal>K</literal>, <literal>M</literal>, <literal>G</literal> and
|
||||
<literal>T</literal> suffixes), or all archived journal files contain no data older than the specified timespan
|
||||
(specified with the usual <literal>s</literal>, <literal>m</literal>, <literal>h</literal>,
|
||||
<literal>days</literal>, <literal>months</literal>, <literal>weeks</literal> and <literal>years</literal>
|
||||
suffixes), or no more than the specified number of separate journal files remain. Note that running
|
||||
<option>--vacuum-size=</option> has only an indirect effect on the output shown by
|
||||
<option>--disk-usage</option>, as the latter includes active journal files, while the vacuuming operation only
|
||||
operates on archived journal files. Similarly, <option>--vacuum-files=</option> might not actually reduce the
|
||||
number of journal files to below the specified number, as it will not remove active journal
|
||||
files.</para>
|
||||
|
||||
<para><option>--vacuum-size=</option>, <option>--vacuum-time=</option> and <option>--vacuum-files=</option>
|
||||
may be combined in a single invocation to enforce any combination of a size, a time and a number of files limit
|
||||
on the archived journal files. Specifying any of these three parameters as zero is equivalent to not enforcing
|
||||
the specific limit, and is thus redundant.</para>
|
||||
|
||||
<para>These three switches may also be combined with <option>--rotate</option> into one command. If so, all
|
||||
active files are rotated first, and the requested vacuuming operation is executed right after. The rotation has
|
||||
the effect that all currently active files are archived (and potentially new, empty journal files opened as
|
||||
replacement), and hence the vacuuming operation has the greatest effect as it can take all log data written so
|
||||
far into account.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -885,9 +892,12 @@
|
||||
<varlistentry>
|
||||
<term><option>--rotate</option></term>
|
||||
|
||||
<listitem><para>Asks the journal daemon to rotate journal
|
||||
files. This call does not return until the rotation operation
|
||||
is complete.</para></listitem>
|
||||
<listitem><para>Asks the journal daemon to rotate journal files. This call does not return until the rotation
|
||||
operation is complete. Journal file rotation has the effect that all currently active journal files are marked
|
||||
as archived and renamed, so that they are never written to in future. New (empty) journal files are then
|
||||
created in their place. This operation may be combined with <option>--vacuum-size=</option>,
|
||||
<option>--vacuum-time=</option> and <option>--vacuum-file=</option> into a single command, see
|
||||
above.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<xi:include href="standard-options.xml" xpointer="help" />
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user