Re: [systemd-devel] [PATCH] util: fix typo
On 04/20/2015 07:27 AM, Raul Gutierrez S wrote:
> Signed-off-by: Raul Gutierrez S
This isn't needed in the systemd project, so I dropped it.
Applied, thanks!
> ---
> src/shared/util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/shared/util.c b/src/shared/util.c
> index 53f8488..f14d9ee 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -1700,7 +1700,7 @@ int parse_size(const char *t, off_t base, off_t *size) {
> * sometimes SI decimal suffixes. This function can parse
> * both. Which one is the right way depends on the
> * context. Wikipedia suggests that SI is customary for
> - * hardrware metrics and network speeds, while IEC is
> + * hardware metrics and network speeds, while IEC is
> * customary for most data sizes used by software and volatile
> * (RAM) memory. Hence be careful which one you pick!
> *
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: fix typo
Signed-off-by: Raul Gutierrez S
---
src/shared/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 53f8488..f14d9ee 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1700,7 +1700,7 @@ int parse_size(const char *t, off_t base, off_t *size) {
* sometimes SI decimal suffixes. This function can parse
* both. Which one is the right way depends on the
* context. Wikipedia suggests that SI is customary for
- * hardrware metrics and network speeds, while IEC is
+ * hardware metrics and network speeds, while IEC is
* customary for most data sizes used by software and volatile
* (RAM) memory. Hence be careful which one you pick!
*
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix trivial typo
*** BLURB HERE *** Raul Gutierrez S (1): util: fix typo src/shared/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] controlling serial console using a token
You mean in the *getty-generator.c ?* On Mon, Apr 20, 2015 at 9:14 AM, Andrei Borzenkov wrote: > В Mon, 20 Apr 2015 09:09:09 +0530 > Praveen kumar R пишет: > > > This is the snippet of the code in the systemV init system that controls > > the serial console login > > depending on the token > > > > TOKENEXIST=`grep "TOKEN=" /proc/cmdline` > > TOKEN=0 > > if [ "X$TOKENEXIST" != "X" ]; then > >#If token is pass as a command line arg, use it. > >TOKEN=`sed 's/.*TOKEN=//; s/ .*//' /proc/cmdline` > > fi > > > > TOKENOVERRIDE=`grep "TOKENOVERRIDE=" /proc/cmdline` > > if [ "X$TOKENOVERRIDE" != "X" ]; then > >#If token is pass as a command line arg, use it. > >OVERRIDE=`sed 's/.*TOKENOVERRIDE=//; s/ .*//' /proc/cmdline` > >let "TOKEN = $TOKEN & $OVERRIDE" > > fi > > > > echo "TOKEN = $TOKEN" > > > > let "CONSOLE_LOGIN = $TOKEN & 512" > > if [ $CONSOLE_LOGIN -ne 0 ]; then > > echo "[`eval $uptime`]: Begin Console Access" > > /etc/console_login & > > echo "eCM console is enabled" > > export ENABLE_ECM_CONSOLE=y > > else > > echo "[`eval $uptime`]: Token doesn't allow console access" > > export ENABLE_ECM_CONSOLE=n > > fi > > > > > > > > I am trying to implement the same in the sytemd init system. > > > > The straightforward approach is to put this code in generator that > parses command line. It can mask standard console service and create > unit for your console. > > > > > On Sun, Apr 19, 2015 at 11:48 AM, Andrei Borzenkov > > wrote: > > > > > В Sat, 18 Apr 2015 19:54:50 +0530 > > > Praveen kumar R пишет: > > > > > > > Yes it's a kernel command line arg, it is board specific token > introduced > > > > to control the serial console. > > > > if defined serial console should not be enabled. > > > > > > > > > > Sorry I do not understand this sentence. "define" what? Please give > > > exact example of kernel command line and explain what behavior you > > > expect in this case. > > > > > > > we have this in place for other system initializing system - sytemV , > > > where > > > > depending > > > > > > > > On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering < > > > lenn...@poettering.net > > > > > wrote: > > > > > > > > > On Fri, 17.04.15 15:54, Praveen kumar R (praveenrgo...@gmail.com > > > > > ) wrote: > > > > > > > > > > > I have a token passed on by command line argument on which I > need to > > > > > decide > > > > > > to start the serial > > > > > > > > > > On which command line? Kernel command line? What kind of "token"? > > > > > > > > > > > console or not. I plan to tweak the getty*ttyS0.service and add > the > > > > > > script which validates the token and starts the console. > > > > > > > > > > > > Is this the right approach or is there any better way of > handling it > > > ?? > > > > > > > > > > To get a login getty on the serial port its sufficient to add > > > > > console=ttyS0... to the kernel cmdline. systemd automatically > starts a > > > > > serial getty automatically on the first terminal the kernel > console is > > > > > pointing to. > > > > > > > > > > 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] controlling serial console using a token
В Mon, 20 Apr 2015 09:09:09 +0530 Praveen kumar R пишет: > This is the snippet of the code in the systemV init system that controls > the serial console login > depending on the token > > TOKENEXIST=`grep "TOKEN=" /proc/cmdline` > TOKEN=0 > if [ "X$TOKENEXIST" != "X" ]; then >#If token is pass as a command line arg, use it. >TOKEN=`sed 's/.*TOKEN=//; s/ .*//' /proc/cmdline` > fi > > TOKENOVERRIDE=`grep "TOKENOVERRIDE=" /proc/cmdline` > if [ "X$TOKENOVERRIDE" != "X" ]; then >#If token is pass as a command line arg, use it. >OVERRIDE=`sed 's/.*TOKENOVERRIDE=//; s/ .*//' /proc/cmdline` >let "TOKEN = $TOKEN & $OVERRIDE" > fi > > echo "TOKEN = $TOKEN" > > let "CONSOLE_LOGIN = $TOKEN & 512" > if [ $CONSOLE_LOGIN -ne 0 ]; then > echo "[`eval $uptime`]: Begin Console Access" > /etc/console_login & > echo "eCM console is enabled" > export ENABLE_ECM_CONSOLE=y > else > echo "[`eval $uptime`]: Token doesn't allow console access" > export ENABLE_ECM_CONSOLE=n > fi > > > > I am trying to implement the same in the sytemd init system. > The straightforward approach is to put this code in generator that parses command line. It can mask standard console service and create unit for your console. > > On Sun, Apr 19, 2015 at 11:48 AM, Andrei Borzenkov > wrote: > > > В Sat, 18 Apr 2015 19:54:50 +0530 > > Praveen kumar R пишет: > > > > > Yes it's a kernel command line arg, it is board specific token introduced > > > to control the serial console. > > > if defined serial console should not be enabled. > > > > > > > Sorry I do not understand this sentence. "define" what? Please give > > exact example of kernel command line and explain what behavior you > > expect in this case. > > > > > we have this in place for other system initializing system - sytemV , > > where > > > depending > > > > > > On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering < > > lenn...@poettering.net > > > > wrote: > > > > > > > On Fri, 17.04.15 15:54, Praveen kumar R (praveenrgo...@gmail.com > > > > ) wrote: > > > > > > > > > I have a token passed on by command line argument on which I need to > > > > decide > > > > > to start the serial > > > > > > > > On which command line? Kernel command line? What kind of "token"? > > > > > > > > > console or not. I plan to tweak the getty*ttyS0.service and add the > > > > > script which validates the token and starts the console. > > > > > > > > > > Is this the right approach or is there any better way of handling it > > ?? > > > > > > > > To get a login getty on the serial port its sufficient to add > > > > console=ttyS0... to the kernel cmdline. systemd automatically starts a > > > > serial getty automatically on the first terminal the kernel console is > > > > pointing to. > > > > > > > > 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] controlling serial console using a token
This is the snippet of the code in the systemV init system that controls the serial console login depending on the token TOKENEXIST=`grep "TOKEN=" /proc/cmdline` TOKEN=0 if [ "X$TOKENEXIST" != "X" ]; then #If token is pass as a command line arg, use it. TOKEN=`sed 's/.*TOKEN=//; s/ .*//' /proc/cmdline` fi TOKENOVERRIDE=`grep "TOKENOVERRIDE=" /proc/cmdline` if [ "X$TOKENOVERRIDE" != "X" ]; then #If token is pass as a command line arg, use it. OVERRIDE=`sed 's/.*TOKENOVERRIDE=//; s/ .*//' /proc/cmdline` let "TOKEN = $TOKEN & $OVERRIDE" fi echo "TOKEN = $TOKEN" let "CONSOLE_LOGIN = $TOKEN & 512" if [ $CONSOLE_LOGIN -ne 0 ]; then echo "[`eval $uptime`]: Begin Console Access" /etc/console_login & echo "eCM console is enabled" export ENABLE_ECM_CONSOLE=y else echo "[`eval $uptime`]: Token doesn't allow console access" export ENABLE_ECM_CONSOLE=n fi I am trying to implement the same in the sytemd init system. On Sun, Apr 19, 2015 at 11:48 AM, Andrei Borzenkov wrote: > В Sat, 18 Apr 2015 19:54:50 +0530 > Praveen kumar R пишет: > > > Yes it's a kernel command line arg, it is board specific token introduced > > to control the serial console. > > if defined serial console should not be enabled. > > > > Sorry I do not understand this sentence. "define" what? Please give > exact example of kernel command line and explain what behavior you > expect in this case. > > > we have this in place for other system initializing system - sytemV , > where > > depending > > > > On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering < > lenn...@poettering.net > > > wrote: > > > > > On Fri, 17.04.15 15:54, Praveen kumar R (praveenrgo...@gmail.com > > > ) wrote: > > > > > > > I have a token passed on by command line argument on which I need to > > > decide > > > > to start the serial > > > > > > On which command line? Kernel command line? What kind of "token"? > > > > > > > console or not. I plan to tweak the getty*ttyS0.service and add the > > > > script which validates the token and starts the console. > > > > > > > > Is this the right approach or is there any better way of handling it > ?? > > > > > > To get a login getty on the serial port its sufficient to add > > > console=ttyS0... to the kernel cmdline. systemd automatically starts a > > > serial getty automatically on the first terminal the kernel console is > > > pointing to. > > > > > > 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] rules: Enable runtime device power management on Intel HDA controllers
On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: > On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett wrote: > > 1) having this in udev makes it easier for users to alter the > > configuration - the kernel can then afford to be conservative until we > > enable power management, rather than potentially breaking the device the > > moment pm is enabled without any ability to recover it. > > There is no significant difference between a default unconditional > udev setting and a kernel command line option to control such behavior > if needed. The command line option would need to be per-device, so I can't see a terribly good way to express that. > > 2) this config is currently static, but the appropriate policy may turn > > out to be more complicated in some scenarios (interactions between > > devices and their upstream bridges, for instance, or USB Bluetooth > > controllers that are on-die with a PCI wifi controller without having a > > common exposed bus topology yet still having pm interactions). Splitting > > this between udev and the kernel makes it more difficult to determine > > the source of the policy and debug it. > > Either the setting is safe to use or not, the source of this policy is > not really relevant here. The loop through userspace does not sound > useful. There's no mechanism in the kernel to say "Enable power management on this USB device only if a specific PCI device doesn't exist". This kind of policy is much easier to express in userspace than in the kernel. > > 3) we already have examples of this in udev, so people already expect to > > find it here. > > Which should be a reason to carefully check these examples if they > should stay in udev, not a reason to justify to add more. Well, that's certainly an option. > I'm not convinced that any such broad matches for power management > belong into udev at all. Udev can carry specific device matches, or > carry data that cannot be determined from the device itself, like the > mouse resolution and such, but like in these rules, reading the vendor > from the kernel and unconditionally flipping a bit back into the > kernel does not look like a task for udev or userspace in general. Is there any possibility that you can be convinced? -- Matthew Garrett | mj...@srcf.ucam.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett wrote: > (Resending from the correct address) > > On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote: > >> It looks like an unconditional static assignment. >> >> Why should udev carry this? We generally do not want to do things like >> that. Udev can help if there is conditional policy or complex >> cross-subsystem knowledge is needed, but this looks just like a job >> for the kernel and not userspace. > > 1) having this in udev makes it easier for users to alter the > configuration - the kernel can then afford to be conservative until we > enable power management, rather than potentially breaking the device the > moment pm is enabled without any ability to recover it. There is no significant difference between a default unconditional udev setting and a kernel command line option to control such behavior if needed. > 2) this config is currently static, but the appropriate policy may turn > out to be more complicated in some scenarios (interactions between > devices and their upstream bridges, for instance, or USB Bluetooth > controllers that are on-die with a PCI wifi controller without having a > common exposed bus topology yet still having pm interactions). Splitting > this between udev and the kernel makes it more difficult to determine > the source of the policy and debug it. Either the setting is safe to use or not, the source of this policy is not really relevant here. The loop through userspace does not sound useful. > 3) we already have examples of this in udev, so people already expect to > find it here. Which should be a reason to carefully check these examples if they should stay in udev, not a reason to justify to add more. I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
В Sun, 19 Apr 2015 13:19:37 + Zbigniew Jędrzejewski-Szmek пишет: > On Sun, Apr 19, 2015 at 09:29:55AM +0300, Andrei Borzenkov wrote: > > В Fri, 17 Apr 2015 16:47:58 + > > Zbigniew Jędrzejewski-Szmek пишет: > > > > > On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote: > > > > Am 2015-02-16 14:16, schrieb Lennart Poettering: > > > > >On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: > > > > >>Not quite. While you can use drop-in snippets to amend > > > > >>orderings/depends, it's (unfortunately) not possible to override > > > > >>Wants=,Before= etc. > > > > > > > > > >There have been discussions to allow masking deps via /dev/null > > > > >symlinks in .wants/ and .requires/ dirs... I think that'd be a better > > > > >solution... > > > > >[...] > > > > >>Agreed, systemctl edit is much nicer. Unfortunately, as said above, > > > > >>drop-ins can *not* be used to override all aspects of a native unit > > > > >>file. So it's not (yet) a complete replacement for insserv > > > > >>overrides. > > > > >> > > > > >>If it would be possible to unset Wants= or After=, just like other > > > > >>service properties, then things would be different. > > > > > > > > > >As mentioned, I'd be happy to take patches to make precisely that > > > > >work! > > > > > > > > Last time I talked about this here, there was a lot of confusion, so > > > > I didn't pursue it further. But I would really like to get this to > > > > work, but before I start with a patch, I'd like to explain what I'd > > > > like to do before working on it, to see if it works for you. > > > > > > > > The semantics I'd like to see would be the following: > > > > > > > > - anything in /etc named exactly the same as in /usr/lib overrides > > > >the latter, just as is already the case with units and drop-ins > > > > > > > > => allow masking of .wants/ and .requires/ with symlinks to > > > > /dev/null (I think you were in favor of that) > > > > > > > > - additionally, postpone processing of dependencies in unit files > > > >until the entire unit (and all drop-ins) have been read in > > > > > > > > For example, even without a drop-in: > > > > > > > > a.service: > > > > [Unit] > > > > Wants=b.service > > > > Wants= > > > > Wants=c.service > > > > > > > > After that, Wants should be set to c.service. Note that this > > > > should NOT affect dependencies set in other ways, i.e. via > > > > .wants/ directories or by dependencies of other services, this > > > > should JUST alter what was specified in the unit itself. > > > > > > > > A more complex example to illustrate the latter: > > > > > > > > /usr/lib/.../a.service: > > > > [Unit] > > > > Wants=b.service > > > > After=c.service > > > > > > > > /usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service > > > > /usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service > > > > > > > > /usr/lib/.../f.service > > > > [Unit] > > > > Before=a.service > > > > > > > > /etc/.../a.service.d/dont-depend-on-b.conf: > > > > [Unit] > > > > Wants= > > > > > > > > /etc/.../a.service.d/not-after-c.conf: > > > > [Unit] > > > > After= > > > > > > > > /etc/.../a.service.wants/e.service -> /dev/null > > > > > > > > In the end, the dependnecies should be: > > > > > > > > Wants=d.service > > > > - b.service gets removed via drop-in > > > > - e.service gets removed because it's masked > > > > - but d.service stays, because it was never defined in > > > > the unit file, so a drop-in doesn't override it, only > > > > the mask does > > > > > > > > After=f.service > > > > - c.service gets removed via drop-in > > > > - f.service is not declared in the original unit file but > > > > rather in f.service as a Before= dependency, so you'd > > > > have to override that to make this go into effect > > > > > > > > The general principle would be: you can drop stuff at the same > > > > place it's defined. If it's defined as After= in a unit, > > > > override it in a drop-in for that unit, if it's defined as > > > > Before= in another unit, override it in a drop-in for the other > > > > unit, and if it's defined in the filesystem via .wants/ or > > > > .requires/, you can override it by masking it in the filesystem. > > > > Only in the end will all remaining dependencies be combined to > > > > make up the entire list of dependencies for that service. > > > > > > > > Would you be agreeable to these semantics? If so, I'll hack up a > > > > patch. > > > Seems quite intuitive to me. Would be great to have this implemented. > > > > > > > Unless I'm mistaken, the only real change is that Wants= will clear > > list, j
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On Sun, Apr 19, 2015 at 09:29:55AM +0300, Andrei Borzenkov wrote: > В Fri, 17 Apr 2015 16:47:58 + > Zbigniew Jędrzejewski-Szmek пишет: > > > On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote: > > > Am 2015-02-16 14:16, schrieb Lennart Poettering: > > > >On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: > > > >>Not quite. While you can use drop-in snippets to amend > > > >>orderings/depends, it's (unfortunately) not possible to override > > > >>Wants=,Before= etc. > > > > > > > >There have been discussions to allow masking deps via /dev/null > > > >symlinks in .wants/ and .requires/ dirs... I think that'd be a better > > > >solution... > > > >[...] > > > >>Agreed, systemctl edit is much nicer. Unfortunately, as said above, > > > >>drop-ins can *not* be used to override all aspects of a native unit > > > >>file. So it's not (yet) a complete replacement for insserv > > > >>overrides. > > > >> > > > >>If it would be possible to unset Wants= or After=, just like other > > > >>service properties, then things would be different. > > > > > > > >As mentioned, I'd be happy to take patches to make precisely that > > > >work! > > > > > > Last time I talked about this here, there was a lot of confusion, so > > > I didn't pursue it further. But I would really like to get this to > > > work, but before I start with a patch, I'd like to explain what I'd > > > like to do before working on it, to see if it works for you. > > > > > > The semantics I'd like to see would be the following: > > > > > > - anything in /etc named exactly the same as in /usr/lib overrides > > >the latter, just as is already the case with units and drop-ins > > > > > > => allow masking of .wants/ and .requires/ with symlinks to > > > /dev/null (I think you were in favor of that) > > > > > > - additionally, postpone processing of dependencies in unit files > > >until the entire unit (and all drop-ins) have been read in > > > > > > For example, even without a drop-in: > > > > > > a.service: > > > [Unit] > > > Wants=b.service > > > Wants= > > > Wants=c.service > > > > > > After that, Wants should be set to c.service. Note that this > > > should NOT affect dependencies set in other ways, i.e. via > > > .wants/ directories or by dependencies of other services, this > > > should JUST alter what was specified in the unit itself. > > > > > > A more complex example to illustrate the latter: > > > > > > /usr/lib/.../a.service: > > > [Unit] > > > Wants=b.service > > > After=c.service > > > > > > /usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service > > > /usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service > > > > > > /usr/lib/.../f.service > > > [Unit] > > > Before=a.service > > > > > > /etc/.../a.service.d/dont-depend-on-b.conf: > > > [Unit] > > > Wants= > > > > > > /etc/.../a.service.d/not-after-c.conf: > > > [Unit] > > > After= > > > > > > /etc/.../a.service.wants/e.service -> /dev/null > > > > > > In the end, the dependnecies should be: > > > > > > Wants=d.service > > > - b.service gets removed via drop-in > > > - e.service gets removed because it's masked > > > - but d.service stays, because it was never defined in > > > the unit file, so a drop-in doesn't override it, only > > > the mask does > > > > > > After=f.service > > > - c.service gets removed via drop-in > > > - f.service is not declared in the original unit file but > > > rather in f.service as a Before= dependency, so you'd > > > have to override that to make this go into effect > > > > > > The general principle would be: you can drop stuff at the same > > > place it's defined. If it's defined as After= in a unit, > > > override it in a drop-in for that unit, if it's defined as > > > Before= in another unit, override it in a drop-in for the other > > > unit, and if it's defined in the filesystem via .wants/ or > > > .requires/, you can override it by masking it in the filesystem. > > > Only in the end will all remaining dependencies be combined to > > > make up the entire list of dependencies for that service. > > > > > > Would you be agreeable to these semantics? If so, I'll hack up a > > > patch. > > Seems quite intuitive to me. Would be great to have this implemented. > > > > Unless I'm mistaken, the only real change is that Wants= will clear > list, just like it does it for ExecStart=. This should be rather > straightforward to implement I guess. Also links in .wants and .requires can be masked. It's not a huge change, but I not trivial either -- and this part of the code is notriously had to get right. Zbyszek
