Re: [systemd-devel] Question about relationship between systemd v219 and kernel version.
On Tue, Apr 07, 2015 at 05:41:48PM -0700, Dimitri John Ledkov wrote: > On 6 April 2015 at 01:12, Lennart Poettering wrote: > > On Mon, 06.04.15 06:17, 임창근 (ck21...@samsung.com) wrote: > > > >> Hello EveryOne. > >> > >> I wonder that If I use kernel v3.4 with systemd v219, systemd-run function > >> is work or not. > >> Because My target have kernel v3.4 and systemd v216. > > > > Please check the README shipped in the tarball, it always lists the > > minimal kernel version systemd requires. For 219 the minimal kernel > > version is 3.7. > > > > I was meant to ask a while back, would it be possible to have degraded > systemd for lower kernels? Quite a few current Android-like phones > will be stuck on 3.4 forever, e.g. those that are shipping SailfishOS > / Ubuntu for Phones / etc. Thus support for 3.4 is desirable to be > maintained, because of the Android phones. I'd recommend taking the time and effort to just forward port the kernel for those devices, considering it's quite out of date and insecure as-is. Or do the work yourself to backport systemd (hint, it might be harder than you think, which is why the dependancy is there...) > At the moment this essentially blocks converting all Ubuntu flavours > to systemd. "all"? Ubuntu ships newer kernels than 3.4, if not, please take it up with that vendor, it's not the community's job to support obsolete, years-old software that everyone has moved on from a long time ago for very good reasons. Remember, never ask a community member to support a business decision of a company, unless you want to show a lack of understanding as to how community-driven software development works. good luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug blocking service start?
В Wed, 08 Apr 2015 10:31:18 +0800 Kai Hendry пишет: > > > On Tue, 7 Apr 2015, at 11:13 PM, Lennart Poettering wrote: > > What does "networkctl status" say when this happens? And "networkctl > > status -a"? > > Oooh, I love those commands. Here is the output which says I'm routable: > > http://s.natalian.org/2015-04-08/networkctl.txt > I am not sure what "configured" means for networkd but comment says /* wait for all links networkd manages to be in admin state 'configured' and at least one link to gain a carrier */ and you have one link in state "configuring". Now if networkd waits for carrier to start configuring interface logic seems to be flawed somewhere. > > Maybe all of this has something to do with the way I've setup > systemd-networkd. I have dejavu now... quite possibly this all is > related to: > https://bugs.freedesktop.org/show_bug.cgi?id=89352 > > > Kind regards, > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
On Tue, Apr 07, 2015 at 02:06:33PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Apr 7, 2015 at 1:52 PM, Hans de Goede wrote:
> > Hi,
> >
> >
> > On 07-04-15 13:46, David Herrmann wrote:
> >>
> >> Hi
> >>
> >> On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede wrote:
>
> The series looks reasonable, but I wonder why we cannot merge it into
> 60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
> case, please make this a builtin of input_id which uses
> udev_device_get_parent_subsystem_devtype() and look for the
> serio/atkbd (?) parent device, instead of hard-coding the path.
> >>>
> >>>
> >>>
> >>> Why would we want to merge this into keyboard rules/hwdb? Trackpoints
> >>> always have a separate driver, input device and event node.
> >>
> >>
> >> Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and
> >> now trackpoint:foobar, instead of a single lookup for evdev:foobar.
> >>
> >> To me, it looks much easier if we have one generic evdev rule, which
> >> searches the hwdb based on the input-modalias via
> >> evdev:input: and the legacy fallback,
> >> evdev:name::
> >>
> >> Depending on what properties where found, we simply apply them to the
> >> evdev node.
> >
> >
> > Ah, I see so what you're suggesting is in essence dropping the
> >
> > ENV{ID_INPUT_KEY}=="", GOTO="keyboard_end"
> >
> > Rule from rules/60-keyboard.rules
> >
> > And s/keyboard/evdev/ as one of Peter's updated patches is already doing,
> > while keeping the hwdb bits the same, except that the prefix for the
> > matches would be evdev instead of pointingstick ?
> >
> > And teaching the keyboard^Wevdev builtin to handle
> > POINTINGSTICK_SENSITIVITY and write the sysfs attribute ?
>
> Exactly. Peter already did most of this in his series, so we might
> wanna wait for him to push it.
> I'm actually only waiting for Kay to ACK the prefix 'evdev', then I'd
> push it myself and we can rebase your series.
just in case, the current tree is here:
https://github.com/whot/systemd/tree/wip/abs-override
Once I have Kay's ack I'll push it unless you beat me to it.
Cheers,
Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug blocking service start?
On Tue, 7 Apr 2015, at 11:13 PM, Lennart Poettering wrote: > What does "networkctl status" say when this happens? And "networkctl > status -a"? Oooh, I love those commands. Here is the output which says I'm routable: http://s.natalian.org/2015-04-08/networkctl.txt Maybe all of this has something to do with the way I've setup systemd-networkd. I have dejavu now... quite possibly this all is related to: https://bugs.freedesktop.org/show_bug.cgi?id=89352 Kind regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] recent udev dependency change delays plymouth and udev
On 2 April 2015 at 00:39, Martin Pitt wrote: > Hello all, > > The recent commit > http://cgit.freedesktop.org/systemd/systemd/commit/?id=d99ce933 (which > also made it into v219-stable at > http://cgit.freedesktop.org/systemd/systemd-stable/commit/?h=v219-stable&id=b238b0eaf71) > fixed a typo in udevd's dependencies, which now results in udev > waiting for systemd-hwdb-update.service. > > While this is certainly "correct" especially for stateless systems, it > is quite a bit inconvenient as it now causes a long dependency chain: > > plymouth-start.service → systemd-udevd.service → systemd-hwdb-update.service → > systemd-remount-fs.service → systemd-fsck-root.service → systemd-fsckd.socket > I dislike building hwdb on boot, thus locally I make sure that update mechanisms have up to date @udevlibexecdir@/hwdb.bin and thus systemd-hwdb-update.service is not run. If triggers rebuild the database, shouldn't the update-process / conditions be modified such that the database is not rebuild on boot? -- Regards, Dimitri. https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Restore udevadm settle timeout
Commit 9ea28c55a2 (udev: remove seqnum API and all assumptions about
seqnums) introduced a regresion, ignoring the timeout option when
waiting until the event queue is empty.
Previously, if the udev event queue was not empty when the timeout was
expired, udevadm settle was returning with exit code 1. To check if the
queue is empty, you could invoke udevadm settle with timeout=0. This
patch restores the previous behavior.
---
src/udev/udevadm-settle.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 0d3025e..715d2e7 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -49,6 +49,7 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
{ "quiet", no_argument, NULL, 'q' }, /* removed
*/
{}
};
+usec_t deadline = 0;
const char *exists = NULL;
unsigned int timeout = 120;
struct pollfd pfd[1] = { {.fd = -1}, };
@@ -98,6 +99,8 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
return EXIT_FAILURE;
}
+deadline = now(CLOCK_MONOTONIC) + timeout * USEC_PER_SEC;
+
/* guarantee that the udev daemon isn't pre-processing */
if (getuid() == 0) {
struct udev_ctrl *uctrl;
@@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
break;
}
+if (now(CLOCK_MONOTONIC) >= deadline)
+break;
+
/* wake up when queue is empty */
if (poll(pfd, 1, MSEC_PER_SEC) > 0 && pfd[0].revents & POLLIN)
udev_queue_flush(queue);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fsckd needs to go
On 3 April 2015 at 05:58, Lennart Poettering wrote: > Heya, > > so we discussed the whole fsckd situation a bit more here in Berlin, > and we came to the conclusion that fsckd really should not exist the > way it does in systemd. > > To start with, the code is really wrong, it should never have been > merged in its current state, the read/write logic for the sockets is > completely borked (I cannot even boot my own machine reliably with > it!). And to my knowledge there has been no attempt to fix all of > that, even though I asked for it. It also doesn't do at all what I > suggested initially, as the flow of data is now fsck → systemd-fsck → > systemd-fsckd → plymouth, and that's just crazy, that's two steps too > many. systemd is supposed to be a few components playing well > together, but certainly not a baroque network of components where data > is passed though four hoops before it reaches the destination... > > Then, there's my general reservation with fsckd at all: file systems > that still require offline fsck are certainly not the future, but we > develop stuff for the future, and the idea to kill an fsck process > while it is running is also very very questionnable. There's a reason Is this about progress & control data or all things fsck? IMHO we do need to continue support ext4, and running fsck.ext4 when enforced, at least from initramfs, with progress output to the user and ability to cancel. Or is even fsck.ext4 obsolete these days and shouldn't be run automatically any more? How this is implemented - e.g. inside systemd project or not, is not relevant, but systemd seems to be a better place for this. In upstart world, this completely was offloaded to mountall which directly passed "special update" messages to plymouthd, which themes could choose to parse and dispaly / act upon. This however was ubuntu-specific patch I believe. The current implementation/integration for systemd-fsck is also heading to plymouth upstream for generic support there in themes, I believe. -- Regards, Dimitri. https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update French translation
On Wed, Apr 8, 2015 at 12:40 AM, Sylvain Plantefève wrote: > Add strings introduced by 5bdf22430e367799dfa66c724144b624c5479518 > --- > po/fr.po | 20 +--- > 1 file changed, 17 insertions(+), 3 deletions(-) > > diff --git a/po/fr.po b/po/fr.po > index f26451f..69862fb 100644 > --- a/po/fr.po > +++ b/po/fr.po > @@ -7,7 +7,7 @@ msgid "" > msgstr "" > "Project-Id-Version: systemd\n" > "Report-Msgid-Bugs-To: \n" > -"POT-Creation-Date: 2015-03-09 18:30+0100\n" > +"POT-Creation-Date: 2015-04-07 20:05+0200\n" > "PO-Revision-Date: 2014-12-28 13:04+0100\n" > "Last-Translator: Sylvain Plantefève \n" > "Language-Team: French\n" > @@ -438,6 +438,20 @@ msgstr "" > "Authentification requise pour verrouiller ou déverrouiller des sessions " > "actives." > > +#: ../src/login/org.freedesktop.login1.policy.in.h:53 > +msgid "Allow indication to the firmware to boot to setup interface" > +msgstr "" > +"Permet d'indiquer au micrologiciel de démarrer sur l'interface de " > +"configuration" > + > +#: ../src/login/org.freedesktop.login1.policy.in.h:54 > +msgid "" > +"Authentication is required to indicate to the firmware to boot to setup " > +"interface." > +msgstr "" > +"Authentification requise pour indiquer au micrologiciel de démarrer sur " > +"l'interface de configuration." > + > #: ../src/machine/org.freedesktop.machine1.policy.in.h:1 > msgid "Log into a local container" > msgstr "Connexion dans un conteneur local" > @@ -512,13 +526,13 @@ msgstr "" > "Authentification requise pour activer ou désactiver la synchronisation de " > "l'heure avec le réseau." > > -#: ../src/fsckd/fsckd.c:186 > +#: ../src/fsckd/fsckd.c:297 > msgid "Press Ctrl+C to cancel all filesystem checks in progress" > msgstr "" > "Appuyez sur Ctrl+C pour annuler toutes vérifications en cours du système de > " > "fichiers" > > -#: ../src/fsckd/fsckd.c:227 > +#: ../src/fsckd/fsckd.c:343 > #, c-format > msgid "Checking in progress on %d disk (%3.1f%% complete)" > msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" > -- Applied. Thanks > 2.1.0 > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about relationship between systemd v219 and kernel version.
On 6 April 2015 at 01:12, Lennart Poettering wrote: > On Mon, 06.04.15 06:17, 임창근 (ck21...@samsung.com) wrote: > >> Hello EveryOne. >> >> I wonder that If I use kernel v3.4 with systemd v219, systemd-run function >> is work or not. >> Because My target have kernel v3.4 and systemd v216. > > Please check the README shipped in the tarball, it always lists the > minimal kernel version systemd requires. For 219 the minimal kernel > version is 3.7. > I was meant to ask a while back, would it be possible to have degraded systemd for lower kernels? Quite a few current Android-like phones will be stuck on 3.4 forever, e.g. those that are shipping SailfishOS / Ubuntu for Phones / etc. Thus support for 3.4 is desirable to be maintained, because of the Android phones. At the moment this essentially blocks converting all Ubuntu flavours to systemd. -- Regards, Dimitri. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 3/4] hwdb: Add entries for the trackpoint on 2 Thinkpads
On Tue, Apr 07, 2015 at 11:37:09AM +0200, Hans de Goede wrote: > Hi, > > On 07-04-15 07:07, Peter Hutterer wrote: > >On Fri, Apr 03, 2015 at 04:11:59PM +0200, Hans de Goede wrote: > >>Lenovo has changed the sensitity of the trackpoint on the x240 / T440s / > >>T540 > > > >s/sensitity/sensitivity/ > > > >>generation of Thinkpads, making them somewhat unsensitive by default, add a > > > >I think it's "insensitive", not unsensitive. > > > >>hwdb entry to tweak the sensitivity setting. > >> > >>The ThinkPad X200s is way way too slow by default and unless you push the > >>trackpoint quite hard only sends delta events in the 1-2 range, tweak the > >>sensitivity to make it send a wider range of deltas and apply a const accel > >>factor to make it have a more reasonable speed by default. > >>--- > >> hwdb/70-pointingstick.hwdb | 14 ++ > >> 1 file changed, 14 insertions(+) > >> > >>diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb > >>index d92434e..ea53019 100644 > >>--- a/hwdb/70-pointingstick.hwdb > >>+++ b/hwdb/70-pointingstick.hwdb > >>@@ -68,3 +68,17 @@ > >> > >> # > >> # Sort by by brand, model > >>+ > >>+# > >>+# Lenovo > >>+# > >>+ > >>+# Lenovo Thinkpad X200s > >>+pointingstick:name:TPPS/2 IBM > >>TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX200s:* > >>+ POINTINGSTICK_SENSITIVITY=200 > >>+ POINTINGSTICK_CONST_ACCEL=1.5 > >>+ > >>+# Lenovo Thinkpad T440s > >>+pointingstick:name:TPPS/2 IBM > >>TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:* > > > >this only catches the T440s, shouldn't we add the 240 and 540 as well then? > > Yes and probably also the x1 from the same generation, etc. The problems are: > > 1) Do we want to enable this on all without even a smoke-test ? > 2) We need to have the DMI strings for these to add entries (I'm pretty sure > we've those in > some old bugs / patches) > > Tonight I should be able to loan an x240 for a few hours then I'll test to > see if it indeed too > is too insensitive by default (according to the interwebs it is) and add an > entry for it too. I'd say if the t440 and the x240 are both affected, the t540 will be too so we can add this untested. Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [syslinux] Read and publish firmware time stamps and boot time
On 04/06/2015 02:13 PM, Paul Menzel via Syslinux wrote: >> >> The kernel boot protocol should probably be extended to accept a block >> of values to be passed from the loader to the OS, and be exported >> somewhere by the kernel itself to userspace. >> We have that, it is called initramfs. It contains a sequence of binary blobs, each of which has a string identifier, usually known as a "filename". The kernel then presents it to userspace as a "file". -hpa ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update French translation
Add strings introduced by 5bdf22430e367799dfa66c724144b624c5479518 --- po/fr.po | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/po/fr.po b/po/fr.po index f26451f..69862fb 100644 --- a/po/fr.po +++ b/po/fr.po @@ -7,7 +7,7 @@ msgid "" msgstr "" "Project-Id-Version: systemd\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2015-03-09 18:30+0100\n" +"POT-Creation-Date: 2015-04-07 20:05+0200\n" "PO-Revision-Date: 2014-12-28 13:04+0100\n" "Last-Translator: Sylvain Plantefève \n" "Language-Team: French\n" @@ -438,6 +438,20 @@ msgstr "" "Authentification requise pour verrouiller ou déverrouiller des sessions " "actives." +#: ../src/login/org.freedesktop.login1.policy.in.h:53 +msgid "Allow indication to the firmware to boot to setup interface" +msgstr "" +"Permet d'indiquer au micrologiciel de démarrer sur l'interface de " +"configuration" + +#: ../src/login/org.freedesktop.login1.policy.in.h:54 +msgid "" +"Authentication is required to indicate to the firmware to boot to setup " +"interface." +msgstr "" +"Authentification requise pour indiquer au micrologiciel de démarrer sur " +"l'interface de configuration." + #: ../src/machine/org.freedesktop.machine1.policy.in.h:1 msgid "Log into a local container" msgstr "Connexion dans un conteneur local" @@ -512,13 +526,13 @@ msgstr "" "Authentification requise pour activer ou désactiver la synchronisation de " "l'heure avec le réseau." -#: ../src/fsckd/fsckd.c:186 +#: ../src/fsckd/fsckd.c:297 msgid "Press Ctrl+C to cancel all filesystem checks in progress" msgstr "" "Appuyez sur Ctrl+C pour annuler toutes vérifications en cours du système de " "fichiers" -#: ../src/fsckd/fsckd.c:227 +#: ../src/fsckd/fsckd.c:343 #, c-format msgid "Checking in progress on %d disk (%3.1f%% complete)" msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update French translation
2015-04-07 20:57 GMT+02:00 Ronny Chevalier : > Hi Sylvain, > > Hi Ronny, > On Tue, Apr 7, 2015 at 8:26 PM, Sylvain Plantefève > wrote: > > Add strings introduced by 5bdf22430e367799dfa66c724144b624c5479518 > > --- > > po/fr.po | 18 +++--- > > 1 file changed, 15 insertions(+), 3 deletions(-) > > > > diff --git a/po/fr.po b/po/fr.po > > index f26451f..3111c49 100644 > > --- a/po/fr.po > > +++ b/po/fr.po > > @@ -7,7 +7,7 @@ msgid "" > > msgstr "" > > "Project-Id-Version: systemd\n" > > "Report-Msgid-Bugs-To: \n" > > -"POT-Creation-Date: 2015-03-09 18:30+0100\n" > > +"POT-Creation-Date: 2015-04-07 20:05+0200\n" > > "PO-Revision-Date: 2014-12-28 13:04+0100\n" > > "Last-Translator: Sylvain Plantefève \n" > > "Language-Team: French\n" > > @@ -438,6 +438,18 @@ msgstr "" > > "Authentification requise pour verrouiller ou déverrouiller des > sessions " > > "actives." > > > > +#: ../src/login/org.freedesktop.login1.policy.in.h:53 > > +msgid "Allow indication to the firmware to boot to setup interface" > > +msgstr "Indiquer au micrologiciel de démarrer sur l'interface de > configuration" > > + > > I think you meant: > > "Permet d'indiquer au micrologiciel [...]" > > Right? > > Ronny > Right, I will resend soon. Sylvain ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] missing.h: Define IFA_F_NOPREFIXROUTE
IFA_F_NOPREFIXROUTE is a usual #define appeared in Linux 3.14, so AC_CHECK_DECLS
is not necessary
---
Fixes second systemd compilation problem against Linux 3.12 uapi headers.
src/shared/missing.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 86c917b..e029167 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -866,6 +866,10 @@ static inline int setns(int fd, int nstype) {
#define IFA_MAX (__IFA_MAX - 1)
#endif
+#ifndef IFA_F_NOPREFIXROUTE
+#define IFA_F_NOPREFIXROUTE 0x200
+#endif
+
#ifndef MAX_AUDIT_MESSAGE_LENGTH
#define MAX_AUDIT_MESSAGE_LENGTH 8970
#endif
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] Update IFA_MAX adding IFA_FLAGS
Fixes the following compilation problem:
src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in initializer
exceeds array bounds
[IFA_FLAGS] = { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization for
'rtnl_address_types')
Also include if_addr.h into missing.h so that it's possible to redefine
__IFA_MAX.
---
src/shared/missing.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index ae84053..86c917b 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -861,6 +862,8 @@ static inline int setns(int fd, int nstype) {
#if !HAVE_DECL_IFA_FLAGS
#define IFA_FLAGS 8
+#define __IFA_MAX 9
+#define IFA_MAX (__IFA_MAX - 1)
#endif
#ifndef MAX_AUDIT_MESSAGE_LENGTH
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi Lennart,
On 07/04/15 21:09, Lennart Poettering wrote:
>>> IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements
>> >
>> > [...]
>> >
> > >> > Oh, sorry, the headers are from 3.12, but that's still newer than
> > >> > 3.8 in the doc...
> > >> >
> > >> > actually wrong, but your patch actually brakes
> > >> > compilation for me. Toolchain
> > >> > is gcc 4.9 custombuilt from buildroot.
>>> > > Got it, we just need documentation update or fallback define as Lennart
>>> > > proposed :)
>> >
>> > I've checked, it appears first in 3.14:
>> >
>> > ...
>> > /*
>> > * Important comment:
>> > * IFA_ADDRESS is prefix address, rather than local interface address.
>> > * It makes no difference for normally configured broadcast interfaces,
>> > * but for point-to-point IFA_ADDRESS is DESTINATION address,
>> > * local address is supplied in IFA_LOCAL attribute.
>> > *
>> > * IFA_FLAGS is a u32 attribute that extends the u8 field ifa_flags.
>> > * If present, the value from struct ifaddrmsg will be ignored.
>> > */
>> > enum {
>> >IFA_UNSPEC,
>> >IFA_ADDRESS,
>> >IFA_LOCAL,
>> >IFA_LABEL,
>> >IFA_BROADCAST,
>> >IFA_ANYCAST,
>> >IFA_CACHEINFO,
>> >IFA_MULTICAST,
>> >IFA_FLAGS,
>> >__IFA_MAX,
>> > };
>> >
>> > #define IFA_MAX (__IFA_MAX - 1)
>> > ...
> Hmm, this header doesn't do "#define IFA_FLAGS IFA_FLAGS" which means
> we need to use AC_CHECK_DECLS for this.
>
> I now made the appropriate change in git. Please test!
Seems IFA_MAX should be changed also:
src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in initializer
exceeds array bounds
[IFA_FLAGS] = { .type = NLA_U32 },
Alex.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi! On 07/04/15 20:49, Lennart Poettering wrote: >> IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements > > >> > from README state 3.8/3.7 at the moment. > > >> > > > >> > One could let the sd_rtnl_message_append_u32 for > > >> > IFA_FLAGS fail in patch > > >> > 2/3, but then user space has to play tricks with IPv6 > > >> > DHCPv6 routes as > > >> > before this patch and needs to re-add the code just > > >> > removed because of > > >> > this nice feature. Oh well... > > >> > I'm building against 3.19 at the moment. Just had no chance to > > >> > check what's >>> > > Oh, sorry, the headers are from 3.12, but that's still newer than 3.8 >>> > > in the doc... >>> > > > > >> > actually wrong, but your patch actually brakes compilation for me. > > >> > Toolchain > > >> > is gcc 4.9 custombuilt from buildroot. >> > >> > Got it, we just need documentation update or fallback define as Lennart >> > proposed :) > We usually try to support the kernels from the last two years in > systemd. That means 3.8 or 3.9 or so., right now. > > Hence we really should add the fallback define to missing.h. But if the backend code for this flag appears first in Linux 3.14 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=479840ffdbe4), working around the compilation issue (against older uapi headers) will not help with the fact that networkd will fail in 851c9f82736 (systemd-networkd: Use IFA_F_NOPREFIXROUTE with IPv6 addresses)? Alex. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
On Tue, 07.04.15 20:01, Alexander Sverdlin (alexander.sverd...@gmail.com) wrote:
> Hi!
>
> On 07/04/15 19:24, Alexander Sverdlin wrote:
> > IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements
>
> [...]
>
> >> > Oh, sorry, the headers are from 3.12, but that's still newer than 3.8 in
> >> > the doc...
> >> >
> >> > actually wrong, but your patch actually brakes compilation for me.
> >> > Toolchain
> >> > is gcc 4.9 custombuilt from buildroot.
> > Got it, we just need documentation update or fallback define as Lennart
> > proposed :)
>
> I've checked, it appears first in 3.14:
>
> ...
> /*
> * Important comment:
> * IFA_ADDRESS is prefix address, rather than local interface address.
> * It makes no difference for normally configured broadcast interfaces,
> * but for point-to-point IFA_ADDRESS is DESTINATION address,
> * local address is supplied in IFA_LOCAL attribute.
> *
> * IFA_FLAGS is a u32 attribute that extends the u8 field ifa_flags.
> * If present, the value from struct ifaddrmsg will be ignored.
> */
> enum {
> IFA_UNSPEC,
> IFA_ADDRESS,
> IFA_LOCAL,
> IFA_LABEL,
> IFA_BROADCAST,
> IFA_ANYCAST,
> IFA_CACHEINFO,
> IFA_MULTICAST,
> IFA_FLAGS,
> __IFA_MAX,
> };
>
> #define IFA_MAX (__IFA_MAX - 1)
> ...
Hmm, this header doesn't do "#define IFA_FLAGS IFA_FLAGS" which means
we need to use AC_CHECK_DECLS for this.
I now made the appropriate change in git. Please test!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update French translation
Hi Sylvain, On Tue, Apr 7, 2015 at 8:26 PM, Sylvain Plantefève wrote: > Add strings introduced by 5bdf22430e367799dfa66c724144b624c5479518 > --- > po/fr.po | 18 +++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/po/fr.po b/po/fr.po > index f26451f..3111c49 100644 > --- a/po/fr.po > +++ b/po/fr.po > @@ -7,7 +7,7 @@ msgid "" > msgstr "" > "Project-Id-Version: systemd\n" > "Report-Msgid-Bugs-To: \n" > -"POT-Creation-Date: 2015-03-09 18:30+0100\n" > +"POT-Creation-Date: 2015-04-07 20:05+0200\n" > "PO-Revision-Date: 2014-12-28 13:04+0100\n" > "Last-Translator: Sylvain Plantefève \n" > "Language-Team: French\n" > @@ -438,6 +438,18 @@ msgstr "" > "Authentification requise pour verrouiller ou déverrouiller des sessions " > "actives." > > +#: ../src/login/org.freedesktop.login1.policy.in.h:53 > +msgid "Allow indication to the firmware to boot to setup interface" > +msgstr "Indiquer au micrologiciel de démarrer sur l'interface de > configuration" > + I think you meant: "Permet d'indiquer au micrologiciel [...]" Right? Ronny ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/5] Cross compilation adjustments
Hi, These are just a few trivial patches fixing cross-compilation build and installation. 1/5 follows what is done everywhere else in the Makefile 2/5 installs arch-specifc pkg-config file to the correct location 3/5 makes use of EFI_CC in the efi part of the configure too 4/5 actually allows to set EFI_CC 5/5 makes use of $(OBJCOPY) instead of harcoding objcopy Marc-Antoine Perennou (5): factory: install to datadir udev.pc: install to pkgconfiglibdir efi: use EFI_CC configure: allow setting EFI_CC build: use $(OBJCOPY) Makefile.am | 11 +-- configure.ac | 4 ++-- 2 files changed, 7 insertions(+), 8 deletions(-) -- 2.3.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/5] build: use $(OBJCOPY)
--- Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 9b769ee..397a71c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects) nm -D -u $@ | grep ' U ' && exit 1 || : $(systemd_boot): $(systemd_boot_solib) - $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \ + $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \ -j .dynsym -j .rel -j .rela -j .reloc \ --target=efi-app-$(EFI_ARCH) $< $@ @@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects) nm -D -u $@ | grep ' U ' && exit 1 || : $(stub): $(stub_solib) - $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \ + $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \ -j .dynsym -j .rel -j .rela -j .reloc \ --target=efi-app-$(EFI_ARCH) $< $@ -- 2.3.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/5] configure: allow setting EFI_CC
and only fallback to gcc
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 1608c83..56340a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1147,7 +1147,7 @@ fi
AM_CONDITIONAL(ENABLE_EFI, [test "x$have_efi" = "xyes"])
#
--
-EFI_CC=gcc
+EFI_CC="${EFI_CC:-gcc}"
AC_SUBST([EFI_CC])
EFI_ARCH=`echo $host | sed "s/\(-\).*$//"`
--
2.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
--- Makefile.am | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 9fa4223..9b769ee 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev dist_udevconf_DATA = \ src/udev/udev.conf -sharepkgconfigdir = $(datadir)/pkgconfig -sharepkgconfig_DATA = \ +pkgconfiglib_DATA += \ src/udev/udev.pc EXTRA_DIST += \ -- 2.3.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/5] efi: use EFI_CC
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 29111f5..1608c83 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1172,7 +1172,7 @@ AS_IF([test "x$enable_gnuefi" != "xno"], [
[AC_MSG_ERROR([*** gnuefi support requested but headers
not found])])
])
-efiroot=$(echo $(cd /usr/lib/$(gcc -print-multi-os-directory); pwd))
+efiroot=$(echo $(cd /usr/lib/$(${EFI_CC} -print-multi-os-directory);
pwd))
EFI_LIB_DIR="$efiroot"
AC_ARG_WITH(efi-libdir,
--
2.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/5] factory: install to datadir
--- Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index a575af6..9fa4223 100644 --- a/Makefile.am +++ b/Makefile.am @@ -109,8 +109,8 @@ udevrulesdir=$(udevlibexecdir)/rules.d udevhwdbdir=$(udevlibexecdir)/hwdb.d catalogdir=$(prefix)/lib/systemd/catalog kernelinstalldir = $(prefix)/lib/kernel/install.d -factory_etcdir = $(prefix)/share/factory/etc -factory_pamdir = $(prefix)/share/factory/etc/pam.d +factory_etcdir = $(datadir)/factory/etc +factory_pamdir = $(datadir)/factory/etc/pam.d bootlibdir = $(prefix)/lib/systemd/boot/efi # And these are the special ones for / -- 2.3.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
On Tue, 07.04.15 19:24, Alexander Sverdlin (alexander.sverd...@gmail.com) wrote: > Hi! > > On 07/04/15 19:09, Alexander Sverdlin wrote: > IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements > >> > from README state 3.8/3.7 at the moment. > >> > > >> > One could let the sd_rtnl_message_append_u32 for IFA_FLAGS fail in > >> > patch > >> > 2/3, but then user space has to play tricks with IPv6 DHCPv6 routes > >> > as > >> > before this patch and needs to re-add the code just removed because > >> > of > >> > this nice feature. Oh well... > >> > I'm building against 3.19 at the moment. Just had no chance to check > >> > what's > > Oh, sorry, the headers are from 3.12, but that's still newer than 3.8 in > > the doc... > > > >> > actually wrong, but your patch actually brakes compilation for me. > >> > Toolchain > >> > is gcc 4.9 custombuilt from buildroot. > > Got it, we just need documentation update or fallback define as Lennart > proposed :) We usually try to support the kernels from the last two years in systemd. That means 3.8 or 3.9 or so., right now. Hence we really should add the fallback define to missing.h. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] po: update French translation
Add strings introduced by 5bdf22430e367799dfa66c724144b624c5479518 --- po/fr.po | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/po/fr.po b/po/fr.po index f26451f..3111c49 100644 --- a/po/fr.po +++ b/po/fr.po @@ -7,7 +7,7 @@ msgid "" msgstr "" "Project-Id-Version: systemd\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2015-03-09 18:30+0100\n" +"POT-Creation-Date: 2015-04-07 20:05+0200\n" "PO-Revision-Date: 2014-12-28 13:04+0100\n" "Last-Translator: Sylvain Plantefève \n" "Language-Team: French\n" @@ -438,6 +438,18 @@ msgstr "" "Authentification requise pour verrouiller ou déverrouiller des sessions " "actives." +#: ../src/login/org.freedesktop.login1.policy.in.h:53 +msgid "Allow indication to the firmware to boot to setup interface" +msgstr "Indiquer au micrologiciel de démarrer sur l'interface de configuration" + +#: ../src/login/org.freedesktop.login1.policy.in.h:54 +msgid "" +"Authentication is required to indicate to the firmware to boot to setup " +"interface." +msgstr "" +"Authentification requise pour indiquer au micrologiciel de démarrer sur " +"l'interface de configuration." + #: ../src/machine/org.freedesktop.machine1.policy.in.h:1 msgid "Log into a local container" msgstr "Connexion dans un conteneur local" @@ -512,13 +524,13 @@ msgstr "" "Authentification requise pour activer ou désactiver la synchronisation de " "l'heure avec le réseau." -#: ../src/fsckd/fsckd.c:186 +#: ../src/fsckd/fsckd.c:297 msgid "Press Ctrl+C to cancel all filesystem checks in progress" msgstr "" "Appuyez sur Ctrl+C pour annuler toutes vérifications en cours du système de " "fichiers" -#: ../src/fsckd/fsckd.c:227 +#: ../src/fsckd/fsckd.c:343 #, c-format msgid "Checking in progress on %d disk (%3.1f%% complete)" msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi!
On 07/04/15 19:24, Alexander Sverdlin wrote:
> IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements
[...]
>> > Oh, sorry, the headers are from 3.12, but that's still newer than 3.8 in
>> > the doc...
>> >
>> > actually wrong, but your patch actually brakes compilation for me.
>> > Toolchain
>> > is gcc 4.9 custombuilt from buildroot.
> Got it, we just need documentation update or fallback define as Lennart
> proposed :)
I've checked, it appears first in 3.14:
...
/*
* Important comment:
* IFA_ADDRESS is prefix address, rather than local interface address.
* It makes no difference for normally configured broadcast interfaces,
* but for point-to-point IFA_ADDRESS is DESTINATION address,
* local address is supplied in IFA_LOCAL attribute.
*
* IFA_FLAGS is a u32 attribute that extends the u8 field ifa_flags.
* If present, the value from struct ifaddrmsg will be ignored.
*/
enum {
IFA_UNSPEC,
IFA_ADDRESS,
IFA_LOCAL,
IFA_LABEL,
IFA_BROADCAST,
IFA_ANYCAST,
IFA_CACHEINFO,
IFA_MULTICAST,
IFA_FLAGS,
__IFA_MAX,
};
#define IFA_MAX (__IFA_MAX - 1)
...
Alex.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] recent udev dependency change delays plymouth and udev
Lennart Poettering [2015-04-03 14:38 +0200]: > I habe now made the suggested change, simpl because it allows greater > parallelization and should be without risk. Cheers! > However, this is not going to solve your problem, and quite frankly I > don't think this is the way to fix your problem at all: you really > shouldn't fsck the root fs that late in the boot anyway. The initrd > should fskc the root fs *before* mounting it. Right, that recently happened in Debian now, and will happen in the next Ubuntu release too. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about timedatectl and NTP
On 07.04.15 at 16:40, Lennart Poettering wrote: > On Sun, 05.04.15 13:25, Jakub Klinkovský (j@gmx.com) wrote: > > > As per systemd 216 NEWS [1], alternative NTP implementations should add > > Conflicts=systemd-timesyncd.service to be recognized by systemd, which > > ntpd.service on Arch Linux does. But still, active ntpd.service does not > > seem > > to be recognized by timedatectl: > > Correct, timedatectl only shows systemd-timesyncd's status now. I have > now updated the man page to clarify this. After looking at the code more thoroughly, I must say that this commit [1] is not entirely correct and might bring some more confusion. There are two different states being reported. The (former) "NTP enabled" field refers to, as you say, only the systemd-timesyncd's status, but the "NTP synchronized" field is general, glibc's adjtimex is used to report the status [2]. [1]: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ff5921bae27b4f3fedb339a3a32dc527c9b3a88c [2]: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/time-util.c#n864 > > > > > $ timedatectl > > ... > > NTP enabled: no > > NTP synchronized: yes > > ... > > > > If I'm reading the code [2] correctly, the 'timedatectl set-ntp' command > > only > > handles systemd-timesyncd.service and does not take into account any other > > NTP > > implementations. This is in contrast with timedatectl(1) [3] which > > explicitly > > shows an example where timedatectl starts chronyd.service. > > Indeed, I fixed this now in the man page, too! > > > Also, I think that since systemd 216 the "NTP enabled" field in > > timedatectl's > > output should read "timesyncd enabled" to avoid confusion. Many people still > > have trouble understanding that NTP != ntpd and timedatectl currently adds > > another term to the inequality. > > Hmm, I have now renamed this in the man page and the output to > "network time synchronization", to disconnect this a bit from the > low-level technology, and as a side-effect hopefully removing the > confusion with the classic ntp package. I agree with using "network time synchronization" in the man page, but can we make it "timesyncd enabled" (or similar) instead of "Network Time on" in the timedatectl's output? The idea is to refer explicitly to systemd-timesyncd in order to avoid confusion with every other network time syncing tool, not only ntpd. > > systemd-timesyncd currently does NTP as well as ensuring a monotonic > clock using a flags file. In the future it hopefully will do PTP too, > one day, hence it probably makes sense to use a more generic term than > just NTP to describe it. After all, our daemon is called > "systemd-timesyncd" rather than "systemd-ntpd", precisely to reflect > that it shall not be bound to one specific protocol. > > > Finally, I think there is a bug in how the Conflicts= specification is > > supposed > > to work. Suppose that systemd-timesyncd.service is inactive and some other > > service, specifying Conflicts=systemd-timesyncd.service is active -- let's > > call > > it ntpd.service as mentioned above. Now, when the user runs > > 'timedatectl set-ntp true' the systemd-timesyncd.service is first enabled > > and > > then started. Due to the Conflicts= declaration, ntpd.service is stopped, > > but > > remains enabled. Later on, when the user reboots, ntpd.service will be > > started > > instead of systemd-timesyncd.service -- this is the behaviour described in > > systemd.unit(5) [4]. > > Hmm, indeed. > > I figure we should add a way to queue a start job that will fail if it > would mean stopping any existing service, and then use this here. That > way timesyncd would not be started if any conflicting NTP service > would already be running, and all should be good. Added this to the > TODO list. -- Jakub Klinkovský pgpOtJz1HDTh2.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi! On 07/04/15 19:09, Alexander Sverdlin wrote: IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements >> > from README state 3.8/3.7 at the moment. >> > >> > One could let the sd_rtnl_message_append_u32 for IFA_FLAGS fail in >> > patch >> > 2/3, but then user space has to play tricks with IPv6 DHCPv6 routes as >> > before this patch and needs to re-add the code just removed because of >> > this nice feature. Oh well... >> > I'm building against 3.19 at the moment. Just had no chance to check what's > Oh, sorry, the headers are from 3.12, but that's still newer than 3.8 in the > doc... > >> > actually wrong, but your patch actually brakes compilation for me. >> > Toolchain >> > is gcc 4.9 custombuilt from buildroot. Got it, we just need documentation update or fallback define as Lennart proposed :) Alex. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi! On 07/04/15 19:06, Alexander Sverdlin wrote: > On 07/04/15 15:55, Patrik Flykt wrote: >> > IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements >> > from README state 3.8/3.7 at the moment. >> > >> > One could let the sd_rtnl_message_append_u32 for IFA_FLAGS fail in patch >> > 2/3, but then user space has to play tricks with IPv6 DHCPv6 routes as >> > before this patch and needs to re-add the code just removed because of >> > this nice feature. Oh well... > I'm building against 3.19 at the moment. Just had no chance to check what's Oh, sorry, the headers are from 3.12, but that's still newer than 3.8 in the doc... > actually wrong, but your patch actually brakes compilation for me. Toolchain > is gcc 4.9 custombuilt from buildroot. Alex. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and nested Btrfs subvolumes
On Sun, 22.03.15 23:15, Chris Murphy (li...@colorremedies.com) wrote: > On Sun, Mar 22, 2015 at 10:50 PM, Lennart Poettering > wrote: > > On Thu, 19.03.15 19:27, Chris Murphy (li...@colorremedies.com) wrote: > > > >> Short version: > >> -- > >> Instead of machinectl clone using btrfs snapshots, or even needing > >> to store things in a var/lib/machines Btrfs subvolume, does it meet > >> the requirements for Btrfs optimization to do this with cp -a > >> --reflink instead? > > > > No. That is neither atomic nor efficient (since it requires opening > > every single file in the tree), not particularly discoverable: I think > > it's a good idea that users can enumerate subvolumes. > > > >> Why? Nested subvolumes are confusing. And nested subvolumes are > >> excluded from snapshots. Subvolume B inside of Subvolume A, will not > >> be snapshot or rolled back, if I snapshot Subvolume A and subsequently > >> rollback to the snapshot of A. Is this the intended workflow? > > > > I am pretty sure the right answer to this problem to get recursive > > snapshotting and subvolume deletion into place, so that the issues go > > away. > > > > The right place to fix this in the kernel, but I figure in the worst > > case this could even be emulated in userspace... > > There is such a patch but there are concerns. And it looks like > snapshot creation isn't atomic right now either. If a subvolume has > heavy writes occurring, and is snapshot, it's uncertain what actually > will end up in the snapshot. > http://www.spinics.net/lists/linux-btrfs/msg29551.html Since Chris said on the btrfs ML that he intends to add recursive snapshot support to userspace I went forward and also added support for recursive subvolume deletion and snapshotting to our userspace. Should the kernel gain support for doing this natively one day, we can easily change our code to make use of it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi! On 07/04/15 15:55, Patrik Flykt wrote: > IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements > from README state 3.8/3.7 at the moment. > > One could let the sd_rtnl_message_append_u32 for IFA_FLAGS fail in patch > 2/3, but then user space has to play tricks with IPv6 DHCPv6 routes as > before this patch and needs to re-add the code just removed because of > this nice feature. Oh well... I'm building against 3.19 at the moment. Just had no chance to check what's actually wrong, but your patch actually brakes compilation for me. Toolchain is gcc 4.9 custombuilt from buildroot. Alex. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit checker tool
On Tue, Apr 07, 2015 at 12:36:31PM -0400, Rahul Sundaram wrote: > Hi > > On Tue, Apr 7, 2015 at 10:49 AM, Lennart Poettering wrote: > > > > > We probably should add chekcs for these to "systemd-analyze verify" > > even... > > > Perhaps packaging guidelines should recommend running this command or it > should be part of the macro that packages include that logs warnings when > unit files has any of these issues The problem is that the way this is currently implemented is that the unit files to check are loaded, and any errors encountered are printed. This means that problems in other units are also reported, even though the unit being checked might not be responsible. (This is not just an implementation issue though. For example, let's say that we are testing A.service, which references B.service, but B.service cannot be read because it has a syntax error. We could filter out anything not directly related to A.service, but this might obscure an issue that will cause A.service to fail. It seems better to report the error for B.service too, if loading A.service causes B.service to be loaded.) Nevertheless, the output from systemd-analyze verify is not really suitable for automatic testing of single unit files. The most interesting problems occur because of conflicts at the level of whole graph of units, so such isolated testing could be implemented, but it would have only limited usefulness. But adding such a mode for automatic testing to catch typos and syntax errors might be reasonable. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] Add reboot to EFI support
On Fri, 03.04.15 18:03, Jan Janssen (medhe...@web.de) wrote: > --- > Changes in v4: > - better logind API naming > - don't write to efi vars if they don't change Thanks, applied! systemctl's new switch goes directly to the EFI system though, currently, and even if we connect to a remote system! Any chance you can rework this to go directly to EFI only on local systems, and with a fallback to logind in any case? With such a logic we should be able to cover all relevant cases: - when run unprivileged logind's PK hookup may allow access to this otherwise priviliged operation - when run on a remote host via -H, going via the bus allows the right thing to happen - when run in early boot with no logind around, the tool would still go directly to EFI, thus allowing the operation to succeed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
On Fri, 03.04.15 19:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: > В Fri, 3 Apr 2015 14:04:10 +0200 > Lennart Poettering пишет: > > > On Thu, 02.04.15 16:28, Martin Pitt (martin.p...@ubuntu.com) wrote: > > > > > Lennart Poettering [2015-04-02 13:03 +0200]: > > > > Yeah, and rightfully so. I mean, a service really should be able to > > > > shutdown if dbus is dead. In fact, it should be able to shutdown in > > > > pretty much any situation... > > > > > > They do, but that's irrelevant here. The problem is that dbus.service > > > shuts down very early as nothing prevents it from that. All > > > dependencies just refer to dbus.socket, but TBH socket (re-)activation > > > totally doesn't work for dbus. > > > > systemd will not reactivate services when shutting down, we refuse to > > go in circles... > > > > Could you elaborate? systemd will obviously start services when > starting shutdown.target. How does systemd differentiate between > services that can and can not be started? Socket units for which a stop job is queued will suppress activations until the stop job is cancelled (ot it is stopped). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?
On Mon, 06.04.15 22:16, Paul Menzel (paulepan...@users.sourceforge.net) wrote: > Am Freitag, den 03.04.2015, 16:47 +0200 schrieb Lennart Poettering: > > On Thu, 02.04.15 13:11, Paul Menzel wrote: > > > > some network cards with certain cables and devices take up to five > > > seconds so that the link is up [1]. > > > > > > $ sudo journalctl -u systemd-networkd > > > -- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 2015-03-22 > > > 08:39:39 CET. -- > > > Mär 20 17:39:31 myhostname systemd-networkd[245]: lo > > > : gained carrier > > > Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0 > > > : link configured > > > Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0 > > > : gained carrier > > > > > > This is annoying if the system is up, but you cannot log into a server > > > because the NIC is so slow configuring the link. > > > > > > The Linux kernel module developers from the e1000-devel mailing list > > > suggested the following [2]: > > > > > > > Both sides either need to be forced or both sides need to be auto-neg. > > > > Otherwise the auto-negotiation process will usually detect link (the > > > > physical signal) but fail to find duplex (since one side is not > > > > talking) and default to the lowest common denominator, e.g. half > > > > duplex. So, you could try forcing speed, it may look right on your > > > > end but if you have no visibility to the other end it could be running > > > > at half duplex. > > > > > > > > You may be able to speed up the auto negotiation process by > > > > exclusively advertising 1000 Mbps Full Duplex. > > > > > > > > # ethtool -s ethX advertise 0x20 > > > > > > In the IRC channel #syst...@irc.freenode.net somebody told me to look > > > into systemd’s network link configuration (`man systemd.link`). > > > > > > Reading the manual page, it’s not clear to me, if auto-negotiation is > > > going to be disabled, if the following is set. > > > > > > BitsPerSecond=1G > > > Duplex=Full > > > > > > Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how > > > could I set that up? > > > > BitsPerSecond= and Duplex= are equivalent to "ethtool speed" and > > "ethtool duplex". > > > > We currently have no setting in .link files that was equivalent to > > "ethtool advertise". Maybe we could add that, Tom? > > > > Paul, are you sure that this will really cut 5s from the configuration > > time? Did you try this? > > I am not sure and didn’t try this, as I do not know where to integrate > that `ethtool -s eth0 advertise …` call. In udev or `systemd-networkd`? > > If somebody could help me, how I can test this, I’ll report my findings > back. Wouldn't it suffice to unplug the ethernet cable, then use ethtool to turn this on, then replug it, and measuring the time until networkd notices the link beat is back? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit checker tool
Hi On Tue, Apr 7, 2015 at 10:49 AM, Lennart Poettering wrote: > > We probably should add chekcs for these to "systemd-analyze verify" > even... Perhaps packaging guidelines should recommend running this command or it should be part of the macro that packages include that logs warnings when unit files has any of these issues Rahul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
On Tue, 07.04.15 16:55, Patrik Flykt (patrik.fl...@linux.intel.com) wrote:
> On Fri, 2015-04-03 at 06:46 +0200, Alexander Sverdlin wrote:
> > Hi!
> >
> > On 25/03/15 14:36, Patrik Flykt wrote:
> > > IFA_FLAGS is a discrete value and has no preprocessor #define defined for
> > > it. Fix this by always using the value.
> >
> > Seems that fix was not a real fix:
> >
> > CC src/libsystemd/sd-id128/libsystemd_internal_la-sd-id128.lo
> > src/libsystemd/sd-rtnl/rtnl-types.c:361:10: error: ‘IFA_FLAGS’ undeclared
> > here (not in a function)
> > [IFA_FLAGS] = { .type = NLA_U32 },
> > ^
> > src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in
> > initializer not of integer type
> > [IFA_FLAGS] = { .type = NLA_U32 },
> > ^
> > src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization for
> > ‘rtnl_address_types’)
> > Makefile:15503: recipe for target
> > 'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
> > make[3]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo]
> > Error 1
>
> IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements
> from README state 3.8/3.7 at the moment.
>
> One could let the sd_rtnl_message_append_u32 for IFA_FLAGS fail in patch
> 2/3, but then user space has to play tricks with IPv6 DHCPv6 routes as
> before this patch and needs to re-add the code just removed because of
> this nice feature. Oh well...
Our general approach is to add missing definitions to missing.h and
thus provide the new functionality only on new kernels but still
compiling on old kernels.
Please add it to missing.h with some #ifdeffery to make sure we use
the system definition if it is available, and all should be good?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] auto-unmount via BindsTo= is annoying
On Sun, 05.04.15 08:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: > When mount unit is not in cache, systemd creates *new* definition and > sets BindsTo current device where filesystem is currently mounted. > > If mount unit is present in cache, it already has some BindsTo. When > systemd processes mountinfo it apparently neither removes old nor adds > new BindsTo for new device. Which makes check kick in later. Dependencies can only be added during runtime, never removed, as systemd doesn't track where dependencies are created from, and we don't really want to track that. The only way to remove deps is by issuing "systemctl daemon-reload" or equivalent. > a) it would be helpful if systemctl status/show could differentiate > between unit loaded due to this systemctl call and unit having been > loaded before. May be "--do-no-load" flag to systemctl or something > like this. systemctl doesn't load units. It's PID 1 that will do so implicitly if a client references it. The client has no concept of loaded or unloaded units, and can trigger loading only really as side affect of accessing a unit that happens to be unloaded. > b) when systemd finds out that What is different in mountinfo, it > should remove BindsTo for old What. May be it should really simply > always drop old mount unit (present in cache) and build new one from > scratch. Or push old definition (to support stacked mounts). Dropping deps is not supported, as mentioned. We need to find a different solution for thi. > c) The resulting unit should be clearly marked as different from > definition on disk. I.e. Internally we already track both settings. > That is obviously wrong. What is mounted now comes *NOT* > from /etc/fstab, and it should not be claiming it. Well, it doesn't claim that. It just says that it loaded stuff from /etc/fstab, but like with all units the state systemd tracks comes from a veriety of sources... I do see that this is a source of confusion so, but I am not too convinced we should export such level of detail over the bus... This is certainly an issue to think about, and I don't really have a good answer right now what to do about this. Note that this issue existed before the recent unmount logic change: each time you mount and unmount a directory with a different source device while it stays referenced we will collect a new dependency for the backing device, and they will not be flushed out until the next daemon reload... Previously it would only collect Wants= deps, and now BindsTo=. In both cases this may bring breakage and confusion, though with the later is certainly more visible... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] auto-unmount via BindsTo= is annoying
On Fri, 03.04.15 21:19, Mantas Mikulėnas (graw...@gmail.com) wrote: > Previously udev used to undo mounts when a device *disappeared;* > when Note really. udev didn't have this functionality at the time I added this to systemd. > ~ Ah, yeah, and if dbus isn't running, systemctl spews out this: > > Error getting authority: Error initializing authority: Could not connect: > > No such file or directory (g-io-error-quark, 1) That's actually not systemctl but the PK command line agent shipped with PolicyKit. Please file a bug against PK to get this changed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd failing sporadically failing to bring up network device
On Sat, Apr 04, 2015 at 12:08:04PM +0100, Sitsofe Wheeler wrote: > Hi, > > I've noticed that networkd occasionally fails to bring up one of two > network interfaces on boot (this happens about once every 70 or so > boots). The machine in question is a VMware ESXi 5.5 guest with two > VMXNET3 network adaptors. When this issue occurs the message > > rtnl: received address for a nonexistent link (1), ignoring > > is present in the journal. > > Does anyone know if this is a known issue in systemd 216 (I'm using > Fedora 21)? I've attached a journal log below: There's been a few post-217 changes related to parsing messages in rtnl, one of which was related to accidentally interpreting change notifications as responses under rare circumstances, so there are some known bugs in 216, but I haven't encountered yours before. Re-testing with the latest systemd snapshot would let us know if it's one of the bugs fixed post 217. If it comes to debugging what netlink is doing, one option is to use the nlmon interface, capture it with tcpdump as described in http://seclists.org/tcpdump/2014/q4/32 and then use wireshark to parse the dump. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn and Qemu compatibility?
On Fri, 03.04.15 14:14, Alison Chaiken (ali...@she-devel.com) wrote: > I've been using Qemu to cross-compile packages and root filesystems > for a while and thought I'd try nspawn instead.While I sometimes > want a full GUI desktop in the walled-off environment, mostly console > is enough, and for that nspawn sounds more efficient. > > Here's the base sequence: > > Install > == > qemu-img create -f raw /opt/debian.raw 50G > qemu-system-x86_64 -machine accel=kvm --enable-kvm --cdrom > /opt/debian.iso -boot d -hda /opt/debian.raw -m 4096 -net > nic,model=e1000 -net user,hostfwd=tcp:127.0.0.1:-:22 -name debian > -localtime -no-reboot > > Boot as Qemu > === > qemu-system-x86_64 -enable-kvm -boot c -hda /opt/debian.raw -m 4096 > -usb -net nic,model=e1000 -net user,hostfwd=tcp:127.0.0.1:-:22 > -name debian -localtime -machine accel=kvm -chardev > spicevmc,id=charchannel1,name=vdagent -chardev pty,id=charconsole0 > (inside Qemu) systemctl poweroff > > Login with nspawn > === > mount -t auto -o ro,loop,offset=1048576 /opt/debian.raw /mnt/loop Why this offset? I'd really recommend letting the kernel figure out the partition table. I.e. use "losetup -P" to enable the kernel partition reading, and then mount the parition directly. Also note that systemd-nspawn in git should be able to do this all automatically for you with the "-i" switch, as long as you either have GPT partition table with the right partition type UUIDs, or you have a GPT/MBR partition table with a single data partition only. > [offset moves past /boot partition to linux ext4] > systemd-nspawn -D /mnt/loop > exit > umount /mnt/loop > > So far, all smiles.However, when I try the same "Boot as Qemu" > instructions again, the kernel comes up, but then "Reading hard disk . > . . " appears, and then nothing. So I guess that using > systemd-nspawn has somehow corrupted the filesystem, although I'm not > sure *why* that would happen.Is there some reason that switching > between nspawn and Qemu should fail, or that nspawn would have a > problem with a loop mount? Should I invoke nspawn differently? Hmm, that#s certainly weird. It's the host kernel that does the file systemd access here, it's not clear to me how that or systemd should corrupt the boot logic. Which boot loader is used? Maybe the boot loader relies on stable sectors or so? otherwise I really have no idea what might be going wrong. Note that our functional tests in systemd actually include a test where we boot the same image via qemu und via nspawn and make sure both times everything boots up correctly, hence this really should work... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug blocking service start?
On Sat, 04.04.15 15:33, Kai Hendry (hen...@webconverger.com) wrote: > Thanks for the reply Lennart! I'm sorry I couldn't attend your FOSSASIA > talk in Singapore. I was on holiday. > > On Sat, 4 Apr 2015, at 12:16 AM, Lennart Poettering wrote: > > something else that runs before it is hanging hence. What does > > "systemctl list-jobs" say before you run this and it hangs? > > [root@rpi2 ~]# systemctl list-jobs > JOB UNIT TYPE STATE > 95 surf.service start waiting > 97 systemd-networkd-wait-online.service start running > 96 network-online.targetstart waiting > > 3 jobs listed. > > > So, maybe the network-online target is not ever bring hit? I'm using > systemd-networkd and I'm certainly online, so I am not sure where the > problem lies. Any ideas? Well, systemd-networkd-wait-online.service apparently disagrees with whether you are online... What does "networkctl status" say when this happens? And "networkctl status -a"? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service runs as imaps, but imaps can not read the journal
On Sat, 04.04.15 09:14, Cecil Westerhof (cldwester...@gmail.com) wrote: > I have the following fetchMail.service file: > [Unit] > Description=Fetch email for the IMAPS server > After=network.target > > [Service] > Type=simple > ExecStart=/home/imaps/bin/fetchMail.sh > Restart=always > User=imaps > StandardError=journal > > [Install] > WantedBy=multi-user.target > > But when I as imaps run: > journalctl --since="2015-04-04 08:00" > > I do not see any log information. Would it not be logical that the user can > see the log information of its own process? > > This is with systemd version 210. See the man page for journal.conf, option SplitMode=. Basically, by default journal only splits up journal files for login sessions, i.e. real "human" users, not system users. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] Some typo fixes to man pages
On Tue, 07.04.15 15:53, Richard Maw (richard@codethink.co.uk) wrote: > I spotted these while looking something up on freedesktop.org. Applied both! Thanks! > > Richard Maw (2): > man: Resolve how to refer to derived names for machinectl containers > man: fix typos in machinectl > > man/machinectl.xml | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > -- > 1.9.1 > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimal systemd configuration
On Sun, 05.04.15 09:56, sdrb (s...@onet.eu) wrote: > Hello, > > I've got a few very basic questions regarding configuration of systemd. > > I'm trying to setup some minimal configuration for qemu running linux. > > The qemu runs linux kernel which mounts nfs-root as root directory. > I've made minimal nfs-root and now I'd like to start the system with systemd > in it. > I copied all the files from /usr/lib/systemd and /etc/systemd from my linux > to nfs-root but when linux runs systemd - I got a lot of error messages like > "[FAILED] Failed to start xxx service". > > My questions are: > > 1. Is there any documentation for creating minimal systemd configuration? I > mean for example - for qemu or embedded systems - with only sshd daemon > running and console to just log into the system? Use ./configure's various --disable switches to disable everything you don't want. > 2. Does the systemd require external applications like mount, login or other > to work properly? Yes, things like mount are strictly necessary, see the README for a list of required dependencies. > 3. Is it possible to reconfigure systemd to run some script at the end of > initialisation? No. This concept is not supported, because "end of initialization" is very vague, conceptionally questionnable, and unclear if people want to run multiple services like this... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] man: Resolve how to refer to derived names for machinectl containers
"the name it is" is clumsy english, and since the most recently referred to thing was a name anyway we can just leave the "it is". This matches later uses in the same document. --- man/machinectl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/machinectl.xml b/man/machinectl.xml index f672915..eee7d0d 100644 --- a/man/machinectl.xml +++ b/man/machinectl.xml @@ -562,7 +562,7 @@ https://, and must refer to a .tar, .tar.gz, .tar.xz or .tar.bz2 -archive file. If the local machine name is omitted the name it +archive file. If the local machine name is omitted it is automatically derived from the last component of the URL, with its suffix removed. @@ -615,7 +615,7 @@ be a .qcow2 or raw disk image, optionally compressed as .gz, .xz, or .bz2. If the -local machine name is omitted the name it is automatically +local machine name is omitted it is automatically derived from the last component of the URL, with its suffix removed. -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] man: fix typos in machinectl
The s/now/not/ unfortunately inverted the meaning. --- man/machinectl.xml | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/man/machinectl.xml b/man/machinectl.xml index eee7d0d..59a6e14 100644 --- a/man/machinectl.xml +++ b/man/machinectl.xml @@ -594,7 +594,7 @@ specify - as local machine name. Note that the read-only subvolume is prefixed with -.tar-, and is thus now shown by +.tar-, and is thus not shown by list-images, unless --all is passed. @@ -623,7 +623,7 @@ (see above). If the the downloaded image is in -.qcow2 format it es converted into a raw +.qcow2 format it is converted into a raw image file before it is made available. Downloaded images of this type will be placed as @@ -635,7 +635,7 @@ Similar to the behaviour of pull-tar, the read-only image is prefixed with -.raw-, and thus now shown by +.raw-, and thus not shown by list-images, unless --all is passed. @@ -667,7 +667,7 @@ - as local machine name. The read-only layer subvolumes are prefixed with -.dkr-, and thus now shown by +.dkr-, and thus not shown by list-images, unless --all is passed. -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/2] Some typo fixes to man pages
I spotted these while looking something up on freedesktop.org. Richard Maw (2): man: Resolve how to refer to derived names for machinectl containers man: fix typos in machinectl man/machinectl.xml | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit checker tool
On Tue, 07.04.15 16:35, Przemyslaw Kedzierski (p.kedzier...@samsung.com) wrote: > Hello, > > We started work on a tool dedicated to check systemd unit files. > Its main purpose will be to parse all or a subset of them, look for > common errors, suboptimal designs. > It will also check single unit file separately or sets of them > referencing one another (for example cycles). Note that "systemd-analyze verify" already checks unit files for correctness. It > We need some help. Could you please describe types of mistakes > that are common, harmful and annoying? Often seen mistakes: - An early-boot service (DefaultDependencies=no) that orders itself after later boot services - Services referencing syslog.target - Late-boot services referencing local-fs.target - Services that needlessly specify StandardError=journal (or even StandardError=syslog) (the former is now the default) We probably should add chekcs for these to "systemd-analyze verify" even... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about timedatectl and NTP
On Sun, 05.04.15 13:25, Jakub Klinkovský (j@gmx.com) wrote: > As per systemd 216 NEWS [1], alternative NTP implementations should add > Conflicts=systemd-timesyncd.service to be recognized by systemd, which > ntpd.service on Arch Linux does. But still, active ntpd.service does not seem > to be recognized by timedatectl: Correct, timedatectl only shows systemd-timesyncd's status now. I have now updated the man page to clarify this. > > $ timedatectl > ... > NTP enabled: no > NTP synchronized: yes > ... > > If I'm reading the code [2] correctly, the 'timedatectl set-ntp' command only > handles systemd-timesyncd.service and does not take into account any other NTP > implementations. This is in contrast with timedatectl(1) [3] which explicitly > shows an example where timedatectl starts chronyd.service. Indeed, I fixed this now in the man page, too! > Also, I think that since systemd 216 the "NTP enabled" field in timedatectl's > output should read "timesyncd enabled" to avoid confusion. Many people still > have trouble understanding that NTP != ntpd and timedatectl currently adds > another term to the inequality. Hmm, I have now renamed this in the man page and the output to "network time synchronization", to disconnect this a bit from the low-level technology, and as a side-effect hopefully removing the confusion with the classic ntp package. systemd-timesyncd currently does NTP as well as ensuring a monotonic clock using a flags file. In the future it hopefully will do PTP too, one day, hence it probably makes sense to use a more generic term than just NTP to describe it. After all, our daemon is called "systemd-timesyncd" rather than "systemd-ntpd", precisely to reflect that it shall not be bound to one specific protocol. > Finally, I think there is a bug in how the Conflicts= specification is > supposed > to work. Suppose that systemd-timesyncd.service is inactive and some other > service, specifying Conflicts=systemd-timesyncd.service is active -- let's > call > it ntpd.service as mentioned above. Now, when the user runs > 'timedatectl set-ntp true' the systemd-timesyncd.service is first enabled and > then started. Due to the Conflicts= declaration, ntpd.service is stopped, but > remains enabled. Later on, when the user reboots, ntpd.service will be started > instead of systemd-timesyncd.service -- this is the behaviour described in > systemd.unit(5) [4]. Hmm, indeed. I figure we should add a way to queue a start job that will fail if it would mean stopping any existing service, and then use this here. That way timesyncd would not be started if any conflicting NTP service would already be running, and all should be good. Added this to the TODO list. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd unit checker tool
Hello, We started work on a tool dedicated to check systemd unit files. Its main purpose will be to parse all or a subset of them, look for common errors, suboptimal designs. It will also check single unit file separately or sets of them referencing one another (for example cycles). We need some help. Could you please describe types of mistakes that are common, harmful and annoying? Thank you Przemek Kedzierski ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fsckd needs to go
On Mon, 06.04.15 15:21, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello all, Heya, > Lennart Poettering [2015-04-03 16:34 +0200]: > > Well, I had a brief look at this patch, but it still doesn't get the > > socket IO stuff right. It uses synchronous fgets() to read things of > > the sockets, that's still not OK, and is a major thing that is > > wrong. > > fsckd kicks malicious/broken fsck clients which send garbage, but if > you want to do the buffering explicitly I can rework the patch to do > that. It's not about sending garbage. It's about blocking. fsckd is supposed to be daemon talking to multiple clients, and hence it may never block. It's how daemons on UNIX work... Hence fgets() on client sockets has *no* place in the fsckd sources. > That is, if we actually keep fsckd in the upstream sources :-) > I wouldn't like to spend time on this if you already pre-decided to > kick this out, but I would ask to reconsider, and instead discuss > what's wrong with the code. Yeah, we decided to remove this, sorry! I can only recommend to fix the async socket IO thing even if you decide to maintain fsckd outside of systemd. It's just broken! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fsckd needs to go
On Mon, 06.04.15 15:12, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello Lennart, all, > > Lennart Poettering [2015-04-03 14:58 +0200]: > > To start with, the code is really wrong, it should never have been > > merged in its current state, the read/write logic for the sockets is > > completely borked (I cannot even boot my own machine reliably with > > it!). > > This is surprising indeed. If that's not just the journald/logind/D-Bus > corruption (which we still haven't tracked down properly), do you have > a journal of a hung boot? We never saw a boot failure due to fsck so > far, so I'm naturally very interested in seeing what's wrong. Sorry, not logs here, I removed the thing already here. Sorry. > > And to my knowledge there has been no attempt to fix all of that, > > even though I asked for it. > > As far as I see, every point that came up during reviews, including > your recent one about "don't route fsck output through systemd-fsck" > got addressed (that latter patch hasn't been committed though, I > thought you wanted to review it yourself). Well, the asnc IO socket handling thing was not dealt with. The newest patches still use fgets(). Using stdio for processing sockets is generally not a good idea, since its blocking. And since you want to process multiple connections at the same time you don't want blocking. This is really broken. Currently, if one fsck sends half a line, then this causes your daemon to hang forever... THis is not acceptable in our sources, sorry. > > It also doesn't do at all what I suggested initially, as the flow of > > data is now fsck → systemd-fsck → systemd-fsckd → plymouth, and > > that's just crazy, that's two steps too many. > > With the above patch it's fsck -> systemd-fsckd → plymouth, and I > don't see how to eliminate yet another step? For example, by making ply listen directly on the socket, instead of making this indirect via fsckd... > > Then, there's my general reservation with fsckd at all: file systems > > that still require offline fsck are certainly not the future, but we > > develop stuff for the future > > I do agree with the sentiment; let me assure you that we don't easily > spend days on such stuff in vain, but it's because there are millions > of existing installations out there which still do have ext4 and fsck. > If systemd upstreams say "we don't care about existing products, only > about a future with just btrfs" that's your prerogative of course, but > distros need to have a more product-oriented focus :-/ This only is a one reason of many. The killer issue really is the safety issue. We shouldn't include code in systemd that makes dangerous things like killing running fscks an easily accessible operation, that has a graphical UI and requires no authentication. > > I hope such a solution is acceptable? > > The data flow is very similar to what we have now, so this mostly > amounts to maintaining fsckd in the systemd sources vs. maintaining it > separately in Debian/Ubuntu. I'd be interested in what > RHEL/SUSE/Arch/etc. want to do. We never had code for this in Fedora/RHEL, and that's not going to change. The ability to have a graphical UI for killing fscks without authentication was an Ubuntu thing, and I figure it's going to stay one. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
On Fri, 2015-04-03 at 06:46 +0200, Alexander Sverdlin wrote:
> Hi!
>
> On 25/03/15 14:36, Patrik Flykt wrote:
> > IFA_FLAGS is a discrete value and has no preprocessor #define defined for
> > it. Fix this by always using the value.
>
> Seems that fix was not a real fix:
>
> CC src/libsystemd/sd-id128/libsystemd_internal_la-sd-id128.lo
> src/libsystemd/sd-rtnl/rtnl-types.c:361:10: error: ‘IFA_FLAGS’ undeclared
> here (not in a function)
> [IFA_FLAGS] = { .type = NLA_U32 },
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in initializer
> not of integer type
> [IFA_FLAGS] = { .type = NLA_U32 },
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization for
> ‘rtnl_address_types’)
> Makefile:15503: recipe for target
> 'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
> make[3]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo]
> Error 1
IFA_FLAGS seems to appear in kernel ~3.13 and the kernel requirements
from README state 3.8/3.7 at the moment.
One could let the sd_rtnl_message_append_u32 for IFA_FLAGS fail in patch
2/3, but then user space has to play tricks with IPv6 DHCPv6 routes as
before this patch and needs to re-add the code just removed because of
this nice feature. Oh well...
Cheers,
Patrik
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [OFF-TOPIC] What's the current status of DRM/KMS device node splitting and single-GPU multiseat support?
Hi there! Some time ago I've read in David Herrmann's blog about DRM/KMS device node splitting project, and now I realised that render node splitting is already merged into kernel and enabled by default since release 3.17, which is going to be included in major distros' next releases. I suppose it's still not sufficient to have finally several Xorg servers running on different outputs of a same graphics card (needed for full single-GPU multiseat), right? What's still lacking? Thanks in advance! -- *Laércio de Sousa* *Orientador de Informática* *Escola Municipal "Professor Eulálio Gruppi"* *Rua Ismael da Silva Mello, 559, Mogi Moderno* *Mogi das Cruzes - SPCEP 08717-390* Telefone: (11) 4726-8313 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
Hi
On Tue, Apr 7, 2015 at 1:52 PM, Hans de Goede wrote:
> Hi,
>
>
> On 07-04-15 13:46, David Herrmann wrote:
>>
>> Hi
>>
>> On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede wrote:
The series looks reasonable, but I wonder why we cannot merge it into
60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
case, please make this a builtin of input_id which uses
udev_device_get_parent_subsystem_devtype() and look for the
serio/atkbd (?) parent device, instead of hard-coding the path.
>>>
>>>
>>>
>>> Why would we want to merge this into keyboard rules/hwdb? Trackpoints
>>> always have a separate driver, input device and event node.
>>
>>
>> Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and
>> now trackpoint:foobar, instead of a single lookup for evdev:foobar.
>>
>> To me, it looks much easier if we have one generic evdev rule, which
>> searches the hwdb based on the input-modalias via
>> evdev:input: and the legacy fallback,
>> evdev:name::
>>
>> Depending on what properties where found, we simply apply them to the
>> evdev node.
>
>
> Ah, I see so what you're suggesting is in essence dropping the
>
> ENV{ID_INPUT_KEY}=="", GOTO="keyboard_end"
>
> Rule from rules/60-keyboard.rules
>
> And s/keyboard/evdev/ as one of Peter's updated patches is already doing,
> while keeping the hwdb bits the same, except that the prefix for the
> matches would be evdev instead of pointingstick ?
>
> And teaching the keyboard^Wevdev builtin to handle
> POINTINGSTICK_SENSITIVITY and write the sysfs attribute ?
Exactly. Peter already did most of this in his series, so we might
wanna wait for him to push it.
I'm actually only waiting for Kay to ACK the prefix 'evdev', then I'd
push it myself and we can rebase your series.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
Hi,
On 07-04-15 13:46, David Herrmann wrote:
Hi
On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede wrote:
The series looks reasonable, but I wonder why we cannot merge it into
60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
case, please make this a builtin of input_id which uses
udev_device_get_parent_subsystem_devtype() and look for the
serio/atkbd (?) parent device, instead of hard-coding the path.
Why would we want to merge this into keyboard rules/hwdb? Trackpoints
always have a separate driver, input device and event node.
Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and
now trackpoint:foobar, instead of a single lookup for evdev:foobar.
To me, it looks much easier if we have one generic evdev rule, which
searches the hwdb based on the input-modalias via
evdev:input: and the legacy fallback,
evdev:name::
Depending on what properties where found, we simply apply them to the
evdev node.
Ah, I see so what you're suggesting is in essence dropping the
ENV{ID_INPUT_KEY}=="", GOTO="keyboard_end"
Rule from rules/60-keyboard.rules
And s/keyboard/evdev/ as one of Peter's updated patches is already doing,
while keeping the hwdb bits the same, except that the prefix for the
matches would be evdev instead of pointingstick ?
And teaching the keyboard^Wevdev builtin to handle
POINTINGSTICK_SENSITIVITY and write the sysfs attribute ?
Regards,
Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
Hi On Tue, Apr 7, 2015 at 1:40 PM, Hans de Goede wrote: >> The series looks reasonable, but I wonder why we cannot merge it into >> 60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that >> case, please make this a builtin of input_id which uses >> udev_device_get_parent_subsystem_devtype() and look for the >> serio/atkbd (?) parent device, instead of hard-coding the path. > > > Why would we want to merge this into keyboard rules/hwdb? Trackpoints > always have a separate driver, input device and event node. Right now, we do hwdb lookups for keyboard:foobar, evdev:foobar and now trackpoint:foobar, instead of a single lookup for evdev:foobar. To me, it looks much easier if we have one generic evdev rule, which searches the hwdb based on the input-modalias via evdev:input: and the legacy fallback, evdev:name:: Depending on what properties where found, we simply apply them to the evdev node. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
Hi,
On 07-04-15 12:23, David Herrmann wrote:
Hi
On Tue, Apr 7, 2015 at 12:09 PM, Hans de Goede wrote:
IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
ps/2 command, which changes the range of the deltas sent when using the
trackpoint. On some models with normal usage only deltas of 1 or 2 are send,
resulting in there only being 2 mouse cursor movement speeds, rather than
the expected fluid scale.
Changing the sensitivity to a higher level than the bootup default fixes this,
the rule additions in this commit allows specifying a new sensitivity default
through hwdb giving a better ootb experience.
---
hwdb/70-pointingstick.hwdb | 12
rules/70-pointingstick.rules | 9 +++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index a893da6..89f4b8a 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -42,6 +42,7 @@
#
# Allowed properties are:
# POINTINGSTICK_CONST_ACCEL
+# POINTINGSTICK_SENSITIVITY
#
#
# POINTINGSTICK_CONST_ACCEL#
@@ -54,6 +55,17 @@
# by how much to multiply deltas generated by the pointingstick to get
# normalized deltas.
#
+#
+# POINTINGSTICK_SENSITIVITY#
+#
+#
+# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
+#POINTINGSTICK_SENSITIVITY=
+#
+# Where is a number between 0 and 255, note this property
+# only applies to TPPS/2 IBM TrackPoint devices, see
+# drivers/input/mouse/trackpoint.c in the Linux kernel sources.
+#
#
# Sort by by brand, model
diff --git a/rules/70-pointingstick.rules b/rules/70-pointingstick.rules
index 5a853f3..15e34a0 100644
--- a/rules/70-pointingstick.rules
+++ b/rules/70-pointingstick.rules
@@ -6,11 +6,16 @@ ENV{ID_INPUT_POINTINGSTICK}=="", GOTO="pointingstick_end"
# skip later rules when we find something for this input device
IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=pointingstick:", \
- GOTO="pointingstick_end"
+ GOTO="pointingstick_apply_settings"
# device matching the input device name and the machine's DMI data
KERNELS=="input*", \
IMPORT{builtin}="hwdb
'pointingstick:name:$attr{device/name}:$attr{[dmi/id]modalias}'", \
- GOTO="pointingstick_end"
+ GOTO="pointingstick_apply_settings"
+
+LABEL="pointingstick_apply_settings"
+
+TEST=="../../../sensitivity", ENV{POINTINGSTICK_SENSITIVITY}!="", \
+ ATTR{../../../sensitivity}="$env{POINTINGSTICK_SENSITIVITY}"
You can read attributes of parents, but writing to them is not that
easy. _Writing_ to ATTR always affects the event-device, not the
matched parent.
Right, and that is what this rule does, it writes an ATTR using the path
from the event-device.
The series looks reasonable, but I wonder why we cannot merge it into
60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
case, please make this a builtin of input_id which uses
udev_device_get_parent_subsystem_devtype() and look for the
serio/atkbd (?) parent device, instead of hard-coding the path.
Why would we want to merge this into keyboard rules/hwdb? Trackpoints
always have a separate driver, input device and event node.
Regards,
Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved service ignores UseDNS=false
Hi On Wed, Mar 25, 2015 at 4:20 AM, Mikhail Morfikov wrote: > In the systemd-resolved manual we can read something like this: > > The DNS servers contacted are determined from the global settings in > resolved.conf(5), the per-link static settings in .network files, and > the per-link dynamic settings received over DHCP. > > 1. Let's say that I have set all the three settings, which one will be > applied? > > 2. If I set the global settings via the /etc/systemd/resolved.conf file, > for instance: > > [Resolve] > DNS=127.0.2.1 > FallbackDNS=208.67.222.222 208.67.220.220 > > will this local resolver be used all the time, even when dhcp > server sends an ip address of other resolver in the network to > the client? > > I don't know how that is supposed to work, but it looks like it doesn't > work in the way I thought it would. So I added some entries to this > /etc/systemd/network/50-bond0-dhcp.network file: > > [Match] > Name=bond0 > > [Network] > Description=Bonded network > DHCP=ipv4 > LinkLocalAddressing=no > DNS=127.0.2.1 > IPForward=true > > [DHCP] > UseDNS=false > UseMTU=false > SendHostname=true > UseHostname=false > UseDomains=true > UseRoutes=true > CriticalConnection=true > RequestBroadcast=true > > And according to the systemd-networkd manual: > > DNS -- a DNS server address, which must be in the format described > in inet_pton(3). This option may be specified more than once. > > UseDNS -- when true (the default), the DNS servers received from the > DHCP server will be used and take precedence over any statically > configured ones. > > (btw, the link to inet_pton is dead) > > So UseDNS is set to false, and I thought the system will be using > the local resolver, but it sometimes uses the local settings and > sometimes not -- it depends on restarting the systemd-resolved > service, for example: > > # ls -al /etc/resolv.conf > lrwxrwxrwx 1 root root 32 2015-02-27 23:52:39 /etc/resolv.conf -> > /run/systemd/resolve/resolv.conf > > # cat /etc/resolv.conf > nameserver 127.0.2.1 > nameserver 192.168.1.1 > search mhouse.lh > > # systemctl restart systemd-resolved.service > # cat /etc/resolv.conf > nameserver 192.168.1.1 > nameserver 127.0.2.1 > search mhouse.lh > > (I've cut the comments for readability) > > As you can see, the two resolvers just switched, and it seems that my > system tries to use the 192.168.1.1 , but I disabled it for testing on > my router. After I ping a domain, I have 10s lag, and then ping go there > and back, so it falls back to the local resolver. > > 3. Shouldn't there be just one resolver in the /etc/resolv.conf file? I'm not 100% sure, but reading networkd-code I'd say there's something going wrong. It should never store the DHCP DNS servers if UseDNS is false. Therefore, resolved should never see them. Cat you look into /run/systemd/netif/links/* and paste the content? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: add Samsung ATIV Book 6 / 8
From: Gavin Li This adds support for the keyboard illumination keys and fixes Fn+F1. --- hwdb/60-keyboard.hwdb | 6 ++ 1 file changed, 6 insertions(+) diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb index 8f0565d..84356cb 100644 --- a/hwdb/60-keyboard.hwdb +++ b/hwdb/60-keyboard.hwdb @@ -1013,6 +1013,12 @@ keyboard:atkbd:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pn*7[34]0U3E*: KEYBOARD_KEY_b3=!prog3 # Fn+F11 fan/cooling mode changer KEYBOARD_KEY_d5=!wlan # Fn+F12 wlan/airplane switch +# ATIV Book 6 / 8 +keyboard:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pn*[68][78]0Z*:pvr* + KEYBOARD_KEY_ce=!prog1 # Fn+F1 launch settings + KEYBOARD_KEY_96=!kbdillumup# Fn+F10 keyboard backlight up + KEYBOARD_KEY_97=!kbdillumdown # Fn+F9 keyboard backlight down + # SQ1US keyboard:atkbd:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pnSQ1US:pvr* KEYBOARD_KEY_d4=menu -- 2.3.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
Hi
On Tue, Apr 7, 2015 at 12:09 PM, Hans de Goede wrote:
> IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
> ps/2 command, which changes the range of the deltas sent when using the
> trackpoint. On some models with normal usage only deltas of 1 or 2 are send,
> resulting in there only being 2 mouse cursor movement speeds, rather than
> the expected fluid scale.
>
> Changing the sensitivity to a higher level than the bootup default fixes this,
> the rule additions in this commit allows specifying a new sensitivity default
> through hwdb giving a better ootb experience.
> ---
> hwdb/70-pointingstick.hwdb | 12
> rules/70-pointingstick.rules | 9 +++--
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
> index a893da6..89f4b8a 100644
> --- a/hwdb/70-pointingstick.hwdb
> +++ b/hwdb/70-pointingstick.hwdb
> @@ -42,6 +42,7 @@
> #
> # Allowed properties are:
> # POINTINGSTICK_CONST_ACCEL
> +# POINTINGSTICK_SENSITIVITY
> #
> #
> # POINTINGSTICK_CONST_ACCEL#
> @@ -54,6 +55,17 @@
> # by how much to multiply deltas generated by the pointingstick to get
> # normalized deltas.
> #
> +#
> +# POINTINGSTICK_SENSITIVITY#
> +#
> +#
> +# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
> +#POINTINGSTICK_SENSITIVITY=
> +#
> +# Where is a number between 0 and 255, note this property
> +# only applies to TPPS/2 IBM TrackPoint devices, see
> +# drivers/input/mouse/trackpoint.c in the Linux kernel sources.
> +#
>
> #
> # Sort by by brand, model
> diff --git a/rules/70-pointingstick.rules b/rules/70-pointingstick.rules
> index 5a853f3..15e34a0 100644
> --- a/rules/70-pointingstick.rules
> +++ b/rules/70-pointingstick.rules
> @@ -6,11 +6,16 @@ ENV{ID_INPUT_POINTINGSTICK}=="", GOTO="pointingstick_end"
>
> # skip later rules when we find something for this input device
> IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=pointingstick:", \
> - GOTO="pointingstick_end"
> + GOTO="pointingstick_apply_settings"
>
> # device matching the input device name and the machine's DMI data
> KERNELS=="input*", \
>IMPORT{builtin}="hwdb
> 'pointingstick:name:$attr{device/name}:$attr{[dmi/id]modalias}'", \
> - GOTO="pointingstick_end"
> + GOTO="pointingstick_apply_settings"
> +
> +LABEL="pointingstick_apply_settings"
> +
> +TEST=="../../../sensitivity", ENV{POINTINGSTICK_SENSITIVITY}!="", \
> + ATTR{../../../sensitivity}="$env{POINTINGSTICK_SENSITIVITY}"
You can read attributes of parents, but writing to them is not that
easy. _Writing_ to ATTR always affects the event-device, not the
matched parent.
The series looks reasonable, but I wonder why we cannot merge it into
60-keyboard.rule (60-evdev.rule now) like Peter's series does? In that
case, please make this a builtin of input_id which uses
udev_device_get_parent_subsystem_devtype() and look for the
serio/atkbd (?) parent device, instead of hard-coding the path.
Thanks
David
> LABEL="pointingstick_end"
> --
> 2.3.4
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 1/4] udev: Add rules and hwdb files for setting pointingstick properties
There is quite a wide spread in the delta events generated by pointingsticks,
some generate deltas of 1-2 under normal use, while others generate deltas
from 1-20.
This commit adds a set of rules + a hwdb file which allows specifying a
per model POINTINGSTICK_CONST_ACCEL value which can be used by the userspace
input stack to normalize the deltas so that all pointingsticks get the same
speed/feeling ootb.
The hwdb matching is modelled after 60-keyboard.rules, rather than after
70-mouse.rules, as pointingsticks are typically (but not always) found
integrated into laptops and the keyboard matching rules are a better match
to this.
---
hwdb/70-pointingstick.hwdb | 59
rules/70-mouse.rules | 1 +
rules/70-pointingstick.rules | 16
3 files changed, 76 insertions(+)
create mode 100644 hwdb/70-pointingstick.hwdb
create mode 100644 rules/70-pointingstick.rules
diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
new file mode 100644
index 000..a893da6
--- /dev/null
+++ b/hwdb/70-pointingstick.hwdb
@@ -0,0 +1,59 @@
+# This file is part of systemd.
+#
+# Pointingstick const-accel configuration, to make different brand / model
+# laptop pointingsticks have the same speed / feel, and per model adjustment
+# of the IBM TrackPoint driver's sensitivty setting
+#
+# The lookup keys are composed in:
+# 70-pointingstick.rules
+#
+# Note: The format of the "pointingstick:" prefix match key is a
+# contract between the rules file and the hardware data, it might
+# change in later revisions to support more or better matches, it
+# is not necessarily expected to be a stable ABI.
+#
+# Supported hardware matches are:
+# - Generic input devices match:
+# pointingstick:input:bvpe-
+#This matches on the kernel modalias of the input-device, mainly:
+# is the bus-id (see /usr/include/linux/input.h BUS_*), , and
+#WWW are the 4-digit hex uppercase vendor, product and version ID and
+#is an arbitrary length input-modalias describing the device capabilities.
+#
+# - Input driver device name and DMI data match:
+# pointingstick:name::dmi:bvn*:bvr*:bd*:svn:pn*
+# is the name device specified by the driver,
+# is the firmware-provided string from the kernel DMI modalias.
+#
+# To add local entries, create a new file
+# /etc/udev/hwdb.d/71-pointingstick-local.hwdb
+# and add your rules there. To load the new rules execute (as root):
+# udevadm hwdb --update
+# udevadm trigger /dev/input/eventXX
+# where /dev/input/eventXX is the pointingstick in question. If in
+# doubt, simply use /dev/input/event* to reload all input rules.
+#
+# If your changes are generally applicable, open a bug report on
+# http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
+# and include your new rules, a description of the device, and the
+# output of
+# udevadm info /dev/input/eventXX
+# (or /dev/input/event*).
+#
+# Allowed properties are:
+# POINTINGSTICK_CONST_ACCEL
+#
+#
+# POINTINGSTICK_CONST_ACCEL#
+#
+#
+# Trackpoint const accel settings are specified as
+#POINTINGSTICK_CONST_ACCEL=
+#
+# Where is a floating point number, using a '.' seperator, specifying
+# by how much to multiply deltas generated by the pointingstick to get
+# normalized deltas.
+#
+
+#
+# Sort by by brand, model
diff --git a/rules/70-mouse.rules b/rules/70-mouse.rules
index 3ea743a..4f1e32d 100644
--- a/rules/70-mouse.rules
+++ b/rules/70-mouse.rules
@@ -3,6 +3,7 @@
ACTION=="remove", GOTO="mouse_end"
KERNEL!="event*", GOTO="mouse_end"
ENV{ID_INPUT_MOUSE}=="", GOTO="mouse_end"
+ENV{ID_INPUT_POINTINGSTICK}=="1", GOTO="mouse_end"
# mouse::vp:name::*
KERNELS=="input*", ENV{ID_BUS}=="usb", \
diff --git a/rules/70-pointingstick.rules b/rules/70-pointingstick.rules
new file mode 100644
index 000..5a853f3
--- /dev/null
+++ b/rules/70-pointingstick.rules
@@ -0,0 +1,16 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION=="remove", GOTO="pointingstick_end"
+KERNEL!="event*", GOTO="pointingstick_end"
+ENV{ID_INPUT_POINTINGSTICK}=="", GOTO="pointingstick_end"
+
+# skip later rules when we find something for this input device
+IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=pointingstick:", \
+ GOTO="pointingstick_end"
+
+# device matching the input device name and the machine's DMI data
+KERNELS=="input*", \
+ IMPORT{builtin}="hwdb
'pointingstick:name:$attr{device/name}:$attr{[dmi/id]modalias}'", \
+ GOTO="pointingstick_end"
+
+LABEL="pointingstick_end"
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 0/4] udev: Add rules and hwdb files for setting pointingstick properties
Hi All,
Here is v3 of my pointingstick set.
Changes since v2:
-Fix numerous spelling / gramatical errors in commit messages
-Add a reference to the kernel sources for the ibm trackpoint sensitivity
setting
Changes since v1:
-Drop the patch to set ID_INPUT_TRACKPOINT, Peter already send almost the
same patch to set ID_INPUT_POINTINGSTICK
-s/trackpoint/pointingstick/ unlike trackpoint pointingstick is a vendor
neutral name, and pointingstick is also what the prop bit is called in
linux/input.h Note that a few occurences where not replaced, as those refer
specifically to IBM/Lenovo trackpoints
-Use ATTR{foo}= to assign sysfs attr value rather then spawning /bin/sh
-Dropped S-o-b from the commit messages
Regards,
Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 3/4] hwdb: Add entries for the trackpoint on 2 Thinkpads
Lenovo has changed the sensitivity of the trackpoint on the x240 / T440s / T540 generation of Thinkpads, making them somewhat insensitive by default, add a hwdb entry to tweak the sensitivity setting. The ThinkPad X200s is way way too slow by default and unless you push the trackpoint quite hard only sends delta events in the 1-2 range, tweak the sensitivity to make it send a wider range of deltas and apply a const accel factor to make it have a more reasonable speed by default. --- hwdb/70-pointingstick.hwdb | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index 89f4b8a..95823a6 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -69,3 +69,17 @@ # # Sort by by brand, model + +# +# Lenovo +# + +# Lenovo Thinkpad X200s +pointingstick:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX200s:* + POINTINGSTICK_SENSITIVITY=200 + POINTINGSTICK_CONST_ACCEL=1.5 + +# Lenovo Thinkpad T440s +pointingstick:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:* + POINTINGSTICK_SENSITIVITY=200 + POINTINGSTICK_CONST_ACCEL=1.0 -- 2.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
ps/2 command, which changes the range of the deltas sent when using the
trackpoint. On some models with normal usage only deltas of 1 or 2 are send,
resulting in there only being 2 mouse cursor movement speeds, rather than
the expected fluid scale.
Changing the sensitivity to a higher level than the bootup default fixes this,
the rule additions in this commit allows specifying a new sensitivity default
through hwdb giving a better ootb experience.
---
hwdb/70-pointingstick.hwdb | 12
rules/70-pointingstick.rules | 9 +++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index a893da6..89f4b8a 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -42,6 +42,7 @@
#
# Allowed properties are:
# POINTINGSTICK_CONST_ACCEL
+# POINTINGSTICK_SENSITIVITY
#
#
# POINTINGSTICK_CONST_ACCEL#
@@ -54,6 +55,17 @@
# by how much to multiply deltas generated by the pointingstick to get
# normalized deltas.
#
+#
+# POINTINGSTICK_SENSITIVITY#
+#
+#
+# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
+#POINTINGSTICK_SENSITIVITY=
+#
+# Where is a number between 0 and 255, note this property
+# only applies to TPPS/2 IBM TrackPoint devices, see
+# drivers/input/mouse/trackpoint.c in the Linux kernel sources.
+#
#
# Sort by by brand, model
diff --git a/rules/70-pointingstick.rules b/rules/70-pointingstick.rules
index 5a853f3..15e34a0 100644
--- a/rules/70-pointingstick.rules
+++ b/rules/70-pointingstick.rules
@@ -6,11 +6,16 @@ ENV{ID_INPUT_POINTINGSTICK}=="", GOTO="pointingstick_end"
# skip later rules when we find something for this input device
IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=pointingstick:", \
- GOTO="pointingstick_end"
+ GOTO="pointingstick_apply_settings"
# device matching the input device name and the machine's DMI data
KERNELS=="input*", \
IMPORT{builtin}="hwdb
'pointingstick:name:$attr{device/name}:$attr{[dmi/id]modalias}'", \
- GOTO="pointingstick_end"
+ GOTO="pointingstick_apply_settings"
+
+LABEL="pointingstick_apply_settings"
+
+TEST=="../../../sensitivity", ENV{POINTINGSTICK_SENSITIVITY}!="", \
+ ATTR{../../../sensitivity}="$env{POINTINGSTICK_SENSITIVITY}"
LABEL="pointingstick_end"
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 4/4] hwdb: Add entries for the pointingstick on 2 Dell Latitudes
The pointingstick of the Dell Latitude E6400 is somewhat slow by default, whereas the pointingstick of the Dell Latitude D620 is much too fast by default, set POINTINGSTICK_CONST_ACCEL for both of them to adjust for this. --- hwdb/70-pointingstick.hwdb | 12 1 file changed, 12 insertions(+) diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index 95823a6..825834e 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -71,6 +71,18 @@ # Sort by by brand, model # +# Dell +# + +# Latitude D620 +pointingstick:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeD620*:pvr* + POINTINGSTICK_CONST_ACCEL=0.5 + +# Latitude E6400 +pointingstick:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE6400*:pvr* + POINTINGSTICK_CONST_ACCEL=1.5 + +# # Lenovo # -- 2.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: input_id: tag pointing sticks as ID_INPUT_POINTINGSTICK
Hi
On Thu, Mar 26, 2015 at 7:05 AM, Peter Hutterer
wrote:
> Also referred to as trackpoint, trackstick. These are marked by recent kernels
> through an input prop. Forward that prop as udev property so userspace can
> easily determine whether there is a pointing stick present.
>
> These devices were previously marked as ID_INPUT_MOUSE, for backwards
> compatibility we keep that in place, the new property is an addition.
> ---
> src/shared/missing.h | 4
> src/udev/udev-builtin-input_id.c | 9 -
> 2 files changed, 12 insertions(+), 1 deletion(-)
For the archives: Pushed to -git
Thanks
David
> diff --git a/src/shared/missing.h b/src/shared/missing.h
> index 802b495..ff461a7 100644
> --- a/src/shared/missing.h
> +++ b/src/shared/missing.h
> @@ -789,3 +789,7 @@ static inline int kcmp(pid_t pid1, pid_t pid2, int type,
> unsigned long idx1, uns
> #ifndef KCMP_FILE
> #define KCMP_FILE 0
> #endif
> +
> +#ifndef INPUT_PROP_POINTING_STICK
> +#define INPUT_PROP_POINTING_STICK 0x05
> +#endif
> diff --git a/src/udev/udev-builtin-input_id.c
> b/src/udev/udev-builtin-input_id.c
> index aa9bc14..4d619bf 100644
> --- a/src/udev/udev-builtin-input_id.c
> +++ b/src/udev/udev-builtin-input_id.c
> @@ -126,6 +126,7 @@ static void test_pointers (struct udev_device *dev,
> const unsigned long* bitmask_abs,
> const unsigned long* bitmask_key,
> const unsigned long* bitmask_rel,
> + const unsigned long* bitmask_props,
> bool test) {
> int is_mouse = 0;
> int is_touchpad = 0;
> @@ -168,6 +169,9 @@ static void test_pointers (struct udev_device *dev,
> udev_builtin_add_property(dev, test,
> "ID_INPUT_JOYSTICK", "1");
> }
>
> +if (test_bit (INPUT_PROP_POINTING_STICK, bitmask_props))
> +udev_builtin_add_property(dev, test,
> "ID_INPUT_POINTINGSTICK", "1");
> +
> if (test_bit (EV_REL, bitmask_ev) &&
> test_bit (REL_X, bitmask_rel) && test_bit (REL_Y, bitmask_rel) &&
> test_bit (BTN_MOUSE, bitmask_key))
> @@ -227,6 +231,7 @@ static int builtin_input_id(struct udev_device *dev, int
> argc, char *argv[], boo
> unsigned long bitmask_abs[NBITS(ABS_MAX)];
> unsigned long bitmask_key[NBITS(KEY_MAX)];
> unsigned long bitmask_rel[NBITS(REL_MAX)];
> +unsigned long bitmask_props[NBITS(INPUT_PROP_MAX)];
> const char *sysname, *devnode;
>
> /* walk up the parental chain until we find the real input device;
> the
> @@ -243,7 +248,9 @@ static int builtin_input_id(struct udev_device *dev, int
> argc, char *argv[], boo
> get_cap_mask(dev, pdev, "capabilities/abs", bitmask_abs,
> sizeof(bitmask_abs), test);
> get_cap_mask(dev, pdev, "capabilities/rel", bitmask_rel,
> sizeof(bitmask_rel), test);
> get_cap_mask(dev, pdev, "capabilities/key", bitmask_key,
> sizeof(bitmask_key), test);
> -test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
> bitmask_rel, test);
> +get_cap_mask(dev, pdev, "properties", bitmask_props,
> sizeof(bitmask_props), test);
> +test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
> + bitmask_rel, bitmask_props, test);
> test_key(dev, bitmask_ev, bitmask_key, test);
> }
>
> --
> 2.3.3
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/6] hwdb: set the resoluton for a couple of bcm5974 touchpads
Hi On Mon, Mar 23, 2015 at 2:30 AM, Peter Hutterer wrote: > Verified for the 5,1 Macbook, the others are guesses based on the list of > supported devices of the moshi trackpad protector. > http://www.moshi.com/trackpad-protector-trackguard-macbook-pro#silver > > Resolution calculated based on the min/max settings set in the kernel driver, > divided by the physical size. This is probably slightly off, but still better > than no resolution at all. > > Signed-off-by: Peter Hutterer > --- > hwdb/60-evdev.hwdb | 40 > 1 file changed, 40 insertions(+) > > diff --git a/hwdb/60-evdev.hwdb b/hwdb/60-evdev.hwdb > index 0d67f87..9a9018f 100644 > --- a/hwdb/60-evdev.hwdb > +++ b/hwdb/60-evdev.hwdb > @@ -35,3 +35,43 @@ > # fields of the struct input_absinfo as listed in linux/input.h. > # If a field is missing the field will be left as-is. Not all fields need to > # be present. e.g. ::45 sets the resolution to 45 units/mm. > + > +# Macbook5,1 (unibody), aka wellspring3 > +evdev:input:b0003v05ACp0236* > +evdev:input:b0003v05ACp0237* > +evdev:input:b0003v05ACp0238* > + EV_ABS_OVERRIDE_00=::92 > + EV_ABS_OVERRIDE_01=::90 > + EV_ABS_OVERRIDE_35=::92 > + EV_ABS_OVERRIDE_36=::90 So the keyboard properties were prefixed by our fake subsystem 'KEYBOARD_', and the entry we change 'KEY_foobar'. Can we do the same for the ABS override? 'EVDEV_ABS_foo=bar'? I don't think 'override' should be in the name. The hwdb simply stores axis information, it's the hwdb-user (builtin-input_id) which decides to override device-values with the hwdb-values. The hwdb doesn't define the policy. Anyway, patches 4+5+6 look good to me! If Kay doesn't have any ideas for a better prefix than 'EVDEV_', I think you can go ahead an push it. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity
Hi, Thanks for the review, v3 with all the commit message corrections taken care of coming up. On 07-04-15 07:06, Peter Hutterer wrote: On Fri, Apr 03, 2015 at 04:11:58PM +0200, Hans de Goede wrote: diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index a893da6..d92434e 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -42,6 +42,7 @@ # # Allowed properties are: # POINTINGSTICK_CONST_ACCEL +# POINTINGSTICK_SENSITIVITY # # # POINTINGSTICK_CONST_ACCEL# @@ -54,6 +55,16 @@ # by how much to multiply deltas generated by the pointingstick to get # normalized deltas. # +# +# POINTINGSTICK_SENSITIVITY# +# +# +# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting +#POINTINGSTICK_SENSITIVITY= +# +# Where is a number between 0 and 255, note this property +# only applies to TPPS/2 IBM TrackPoint devices. maybe add a comment here that to the kernel driver file for reference? And v3 has this fixed as well. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 5/6] udev: builtin-keyboard: add support for EV_ABS_OVERRIDE
Hi
On Tue, Apr 7, 2015 at 2:15 AM, Peter Hutterer wrote:
> On Fri, Mar 27, 2015 at 12:54:50PM +0100, Martin Pitt wrote:
>> Hey Peter,
>>
>> thanks for these! Patches 1 to 4 look good to me, but I have some
>> questions/comments on this one.
>>
>> Peter Hutterer [2015-03-23 11:30 +1000]:
>> > --- /dev/null
>> > +++ b/rules/60-evdev.rules
>> > @@ -0,0 +1,14 @@
>> > +# do not edit this file, it will be overwritten on update
>> > +
>> > +ACTION=="remove", GOTO="evdev_end"
>> > +KERNEL!="event*", GOTO="evdev_end"
>> > +
>> > +# skip later rules when we find something for this input device
>> > +IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=evdev:", \
>> > + RUN{builtin}+="keyboard", GOTO="evdev_end"
>> > +
>> > +# device matching the input device name and the machine's DMI data
>> > +KERNELS=="input*", IMPORT{builtin}="hwdb
>> > 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
>> > + RUN{builtin}+="keyboard", GOTO="evdev_end"
>>
>> With this we would then call the hwdb builtin here, and another time
>> in 60-keyboard.rules, except that that one uses a "keyboard:" prefix.
>> I wonder if we could use the generalized "evdev:" for all of them?
>
> works for me if we don't have emotional attachment to the keyboard prefix :)
> patch coming up.
No emotional attachment, but we usually avoid purely technical
acronyms if we have human descriptions for it. So "input" would be the
prefix of choice here, if it weren't already reserved for the kernel
subsystem.
Not sure what else to use.. so I'd be fine with 'evdev' for now. It's
internal, so we can change it at any time.
Thanks
David
>> > +static int open_device(const char *devnode) {
>> > +int fd = open(devnode, O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
>>
>> I think calling functions in variable declarations is frowned upon in
>> the systemd code.
>
> fixed locally, thanks.
Yes, just add the newlines:
int fd;
fd = open();
if (fd < 0)
log_foobar()
return fd < 0 ? -errno : fd;
Thanks
David
> Cheers,
>Peter
>
>>
>> The rest LGTM, thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/6] udev: builtin-keyboard: move actual key mapping to a helper function
Hi
On Mon, Mar 23, 2015 at 2:30 AM, Peter Hutterer
wrote:
> No changes in the mapping, but previously we opened the device only on
> successful parsing. Now we open the mapping as soon as we have a value that
> looks interesting. Since errors are supposed to be the exception, not the
> rule, this is probably fine.
> ---
> src/udev/udev-builtin-keyboard.c | 59
> ++--
> 1 file changed, 33 insertions(+), 26 deletions(-)
All fine, please push!
Thanks
David
> diff --git a/src/udev/udev-builtin-keyboard.c
> b/src/udev/udev-builtin-keyboard.c
> index b3396d5..8353249 100644
> --- a/src/udev/udev-builtin-keyboard.c
> +++ b/src/udev/udev-builtin-keyboard.c
> @@ -62,12 +62,41 @@ static int install_force_release(struct udev_device *dev,
> const unsigned *releas
> return ret;
> }
>
> -static int builtin_keyboard(struct udev_device *dev, int argc, char *argv[],
> bool test) {
> -struct udev_list_entry *entry;
> +static void map_keycode(int fd, const char *devnode, int scancode, const
> char *keycode)
> +{
> struct {
> unsigned scan;
> unsigned key;
> } map;
> +char *endptr;
> +const struct key *k;
> +unsigned keycode_num;
> +
> +/* translate identifier to key code */
> +k = keyboard_lookup_key(keycode, strlen(keycode));
> +if (k) {
> +keycode_num = k->id;
> +} else {
> +/* check if it's a numeric code already */
> +keycode_num = strtoul(keycode, &endptr, 0);
> +if (endptr[0] !='\0') {
> +log_error("Error, unknown key identifier '%s'",
> keycode);
> +return;
> +}
> +}
> +
> +map.scan = scancode;
> +map.key = keycode_num;
> +
> +log_debug("keyboard: mapping scan code %d (0x%x) to key code %d
> (0x%x)",
> + map.scan, map.scan, map.key, map.key);
> +
> +if (ioctl(fd, EVIOCSKEYCODE, &map) < 0)
> +log_error_errno(errno, "Error calling EVIOCSKEYCODE on
> device node '%s' (scan code 0x%x, key code %d): %m", devnode, map.scan,
> map.key);
> +}
> +
> +static int builtin_keyboard(struct udev_device *dev, int argc, char *argv[],
> bool test) {
> +struct udev_list_entry *entry;
> unsigned release[1024];
> unsigned release_count = 0;
> _cleanup_close_ int fd = -1;
> @@ -82,10 +111,9 @@ static int builtin_keyboard(struct udev_device *dev, int
> argc, char *argv[], boo
>
> udev_list_entry_foreach(entry,
> udev_device_get_properties_list_entry(dev)) {
> const char *key;
> -unsigned scancode, keycode_num;
> char *endptr;
> +unsigned scancode;
> const char *keycode;
> -const struct key *k;
>
> key = udev_list_entry_get_name(entry);
> if (!startswith(key, "KEYBOARD_KEY_"))
> @@ -112,19 +140,6 @@ static int builtin_keyboard(struct udev_device *dev, int
> argc, char *argv[], boo
> continue;
> }
>
> -/* translate identifier to key code */
> -k = keyboard_lookup_key(keycode, strlen(keycode));
> -if (k) {
> -keycode_num = k->id;
> -} else {
> -/* check if it's a numeric code already */
> -keycode_num = strtoul(keycode, &endptr, 0);
> -if (endptr[0] !='\0') {
> -log_error("Error, unknown key identifier
> '%s'", keycode);
> -continue;
> -}
> -}
> -
> if (fd == -1) {
> fd = open(node,
> O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
> if (fd < 0) {
> @@ -133,15 +148,7 @@ static int builtin_keyboard(struct udev_device *dev, int
> argc, char *argv[], boo
> }
> }
>
> -map.scan = scancode;
> -map.key = keycode_num;
> -
> -log_debug("keyboard: mapping scan code %d (0x%x) to key code
> %d (0x%x)",
> - map.scan, map.scan, map.key, map.key);
> -
> -if (ioctl(fd, EVIOCSKEYCODE, &map) < 0)
> -log_error_errno(errno, "Error calling EVIOCSKEYCODE
> on device node '%s' (scan code 0x%x, key code %d): %m", node, map.scan,
> map.key);
> -
> +map_keycode(fd, node, scancode, keycode);
> }
>
> /* install list of force-release codes */
> --
> 2.3.2
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/6] udev: builtin-keyboard: immediately EVIOCSKEYCODE when we have a pair
Hi
On Mon, Mar 23, 2015 at 2:30 AM, Peter Hutterer
wrote:
> Rather than building a map and looping through the map, immediately call the
> ioctl when we have a successfully parsed property.
>
> This has a side-effect: before the maximum number of ioctls was limited to the
> size of the map (1024), now it is unlimited.
> ---
> src/udev/udev-builtin-keyboard.c | 46
> +---
> 1 file changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/src/udev/udev-builtin-keyboard.c
> b/src/udev/udev-builtin-keyboard.c
> index b7c8791..b3396d5 100644
> --- a/src/udev/udev-builtin-keyboard.c
> +++ b/src/udev/udev-builtin-keyboard.c
> @@ -67,10 +67,10 @@ static int builtin_keyboard(struct udev_device *dev, int
> argc, char *argv[], boo
> struct {
> unsigned scan;
> unsigned key;
> -} map[1024];
> -unsigned map_count = 0;
> +} map;
> unsigned release[1024];
> unsigned release_count = 0;
> +_cleanup_close_ int fd = -1;
> const char *node;
>
> node = udev_device_get_devnode(dev);
> @@ -125,37 +125,29 @@ static int builtin_keyboard(struct udev_device *dev,
> int argc, char *argv[], boo
> }
> }
>
> -map[map_count].scan = scancode;
> -map[map_count].key = keycode_num;
> -if (map_count < ELEMENTSOF(map)-1)
> -map_count++;
> -}
> -
> -if (map_count > 0 || release_count > 0) {
> -int fd;
> -unsigned i;
> -
> -fd = open(node, O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
> -if (fd < 0) {
> -log_error_errno(errno, "Error, opening device '%s':
> %m", node);
> -return EXIT_FAILURE;
> +if (fd == -1) {
> +fd = open(node,
> O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
> +if (fd < 0) {
> +log_error_errno(errno, "Error, opening
> device '%s': %m", node);
> +return EXIT_FAILURE;
> +}
> }
>
> -/* install list of map codes */
> -for (i = 0; i < map_count; i++) {
> -log_debug("keyboard: mapping scan code %d (0x%x) to
> key code %d (0x%x)",
> - map[i].scan, map[i].scan, map[i].key,
> map[i].key);
> -if (ioctl(fd, EVIOCSKEYCODE, &map[i]) < 0)
> -log_error_errno(errno, "Error calling
> EVIOCSKEYCODE on device node '%s' (scan code 0x%x, key code %d): %m", node,
> map[i].scan, map[i].key);
> -}
> +map.scan = scancode;
> +map.key = keycode_num;
> +
> +log_debug("keyboard: mapping scan code %d (0x%x) to key code
> %d (0x%x)",
> + map.scan, map.scan, map.key, map.key);
>
> -/* install list of force-release codes */
> -if (release_count > 0)
> -install_force_release(dev, release, release_count);
> +if (ioctl(fd, EVIOCSKEYCODE, &map) < 0)
Man, this ioctl is ugly. Why has there never been a payload-struct? We
might convert this to EVIOCSKEYCODE_V2 some day.. but unrelated to
this change.
> +log_error_errno(errno, "Error calling EVIOCSKEYCODE
> on device node '%s' (scan code 0x%x, key code %d): %m", node, map.scan,
> map.key);
>
Weird empty line left?
Looks all good to me. Please push!
David
> -close(fd);
> }
>
> +/* install list of force-release codes */
> +if (release_count > 0)
> +install_force_release(dev, release, release_count);
> +
> return EXIT_SUCCESS;
> }
>
> --
> 2.3.2
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 3/4] hwdb: Add entries for the trackpoint on 2 Thinkpads
Hi, On 07-04-15 07:07, Peter Hutterer wrote: On Fri, Apr 03, 2015 at 04:11:59PM +0200, Hans de Goede wrote: Lenovo has changed the sensitity of the trackpoint on the x240 / T440s / T540 s/sensitity/sensitivity/ generation of Thinkpads, making them somewhat unsensitive by default, add a I think it's "insensitive", not unsensitive. hwdb entry to tweak the sensitivity setting. The ThinkPad X200s is way way too slow by default and unless you push the trackpoint quite hard only sends delta events in the 1-2 range, tweak the sensitivity to make it send a wider range of deltas and apply a const accel factor to make it have a more reasonable speed by default. --- hwdb/70-pointingstick.hwdb | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb index d92434e..ea53019 100644 --- a/hwdb/70-pointingstick.hwdb +++ b/hwdb/70-pointingstick.hwdb @@ -68,3 +68,17 @@ # # Sort by by brand, model + +# +# Lenovo +# + +# Lenovo Thinkpad X200s +pointingstick:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX200s:* + POINTINGSTICK_SENSITIVITY=200 + POINTINGSTICK_CONST_ACCEL=1.5 + +# Lenovo Thinkpad T440s +pointingstick:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:* this only catches the T440s, shouldn't we add the 240 and 540 as well then? Yes and probably also the x1 from the same generation, etc. The problems are: 1) Do we want to enable this on all without even a smoke-test ? 2) We need to have the DMI strings for these to add entries (I'm pretty sure we've those in some old bugs / patches) Tonight I should be able to loan an x240 for a few hours then I'll test to see if it indeed too is too insensitive by default (according to the interwebs it is) and add an entry for it too. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/6] udev: builtin-keyboard: move fetching the device node up
Hi
On Mon, Mar 23, 2015 at 2:30 AM, Peter Hutterer
wrote:
> No point parsing the properties if we can't get the devnode to apply them
> later. Plus, this makes future additions easier to slot in.
> ---
> src/udev/udev-builtin-keyboard.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/src/udev/udev-builtin-keyboard.c
> b/src/udev/udev-builtin-keyboard.c
> index 8ab1be8..b7c8791 100644
> --- a/src/udev/udev-builtin-keyboard.c
> +++ b/src/udev/udev-builtin-keyboard.c
> @@ -71,6 +71,14 @@ static int builtin_keyboard(struct udev_device *dev, int
> argc, char *argv[], boo
> unsigned map_count = 0;
> unsigned release[1024];
> unsigned release_count = 0;
> +const char *node;
> +
> +node = udev_device_get_devnode(dev);
> +
Please drop that newline. Otherwise looks good, please push!
Thanks
David
> +if (!node) {
> +log_error("Error, no device node for '%s'",
> udev_device_get_syspath(dev));
> +return EXIT_FAILURE;
> +}
>
> udev_list_entry_foreach(entry,
> udev_device_get_properties_list_entry(dev)) {
> const char *key;
> @@ -124,17 +132,10 @@ static int builtin_keyboard(struct udev_device *dev,
> int argc, char *argv[], boo
> }
>
> if (map_count > 0 || release_count > 0) {
> -const char *node;
> int fd;
> unsigned i;
>
> -node = udev_device_get_devnode(dev);
> -if (!node) {
> -log_error("Error, no device node for '%s'",
> udev_device_get_syspath(dev));
> -return EXIT_FAILURE;
> -}
> -
> -fd = open(udev_device_get_devnode(dev),
> O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
> +fd = open(node, O_RDWR|O_CLOEXEC|O_NONBLOCK|O_NOCTTY);
> if (fd < 0) {
> log_error_errno(errno, "Error, opening device '%s':
> %m", node);
> return EXIT_FAILURE;
> --
> 2.3.2
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: input_id: tag accelerometers as ID_INPUT_ACCELEROMETER
Hi On Tue, Apr 7, 2015 at 3:47 AM, Peter Hutterer wrote: > On Sat, Apr 04, 2015 at 02:07:27PM +0200, David Herrmann wrote: >> Hi >> >> On Fri, Apr 3, 2015 at 8:55 PM, Hans de Goede wrote: >> [...] >> >> I don't think we should return when we see INPUT_PROP_ACCEL. If a >> >> keyboard embeds an accelerometer, we will miss it. I think I went too >> >> deep in detail for Wacoms/tablets devices and it confused you. Those >> >> don't need much processing in udev, we can mostly control everything >> >> out the tree. >> > >> > >> > Ok, I'll respin my patch to not have the return then. >> >> What's the plan? Use INPUT_PROP_ACCEL as "negative check" (necessary >> negative condition) for touchpads and mice? And as fallback hint for >> accelerometer if nothing else matched? [...] > If we know that the x/y axes are accelerometers we know the device isn't a > touchpad, mouse, pointing stick or touchscreen. The open question was whether this will remain true in the future. But I guess this assumption is pretty solid and we just ought to fix kernel drivers that feed multiple input streams into a single evdev device. So yeah, patch is fine with me. Thanks for pushing! David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
