Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On 03.04.2014 00:27, Greg KH wrote: If the kernel is started with debug, that's for the kernel to switch into debug mode. We should rely on a namespace for our options, like everything else (with the exception of quiet). Some people want to only debug the kernel, not systemd, and the opposite as well so make everyone happy. Allow me to propose an alternative to 'debug' and 'systemd.debug'. When I debug boot issues and add 'debug' to the kernel command line, I do it by editing the command line through the boot loader and I might do it several times in a row, so I want the option to be short. I imagine that's a common workflow and is one of the reasons everybody wants to claim 'debug'. I suggest we return the 'debug' option to the kernel folk and add a new option 'dbg' with a string of single letter arguments. For example, 'dbg=ki' (k for kernel, i for init) would activate debugging in the kernel and the init system. Further, r could be added for initrd debugging and 'dbg' on it's own could default to 'dbg=kri'. The new option would be short, flexible, and extensible, 'debug' could still be used by kernel developers as they are used to, and it's trivial to implement. Wouldn't that make everyone happy? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On 03.04.2014 15:48, Colin Guthrie wrote: 'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did gyre and gimble: I suggest we return the 'debug' option to the kernel folk and add a new option 'dbg' with a string of single letter arguments. For example, 'dbg=ki' (k for kernel, i for init) would activate debugging in the kernel and the init system. Further, r could be added for initrd debugging and 'dbg' on it's own could default to 'dbg=kri'. I think this is a reasonable suggestion inline with the spirit of finding a compromise. You would first have to get agreement in principle from both sides that merging patches to support this would be OK. Of course. I figured, I would start with the presumably easier side first ;) I would suggest that instead of an argument you make dbg a general purpose debug namesapce prefix. So, dbg.k or dbg.kernel works on the kernel side, and dbg.i or dbg.init works on the systemd side with dbg.r and dbg.rd works on the the dracut side. Style-wise I tend to agree, but I was going for brevity first and foremost. Wouldn't that make everyone happy? I doubt it. People would still disagree on what colour to make the argument text ;) Everyone is a big crowd, should have said more people, then maybe… Overall in this issue, I think one has to have a bit of pragmatism. I agree in principle that debug should be a generic term, but really there are bigger fights to fight and wasting energy on this battle really seems counter productive to the bigger picture. Agreed. I'm only mildly interested because of the fresh memory of typing 'debug rd.debug ...' repeatedly over a day. Would have been nice to have - not worth fighting anyone, though. I think in this case, there is a little prior art to using debug on the kernel where dracut used a namespaced version rd.debug for it's debugging, so following that pattern systemd.debug seems logical enough. It's definitely logical, but that's not my point at all. I know it would be nice to have one argument to turn all debugging on, but ultimately I feel there are bigger fish to fry than points of principle here. Both you and Tom Gundersen raised the point of assisting end-users with boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as concise and simple as it gets. As far as I understand it none of the future plans really revolve around this, so I say just change it and move on with making things awesome and don't waste time on this point of principle. I'm not going to push it, but if anyone (important) wants me to, I'm still willing to bring it up on LKML and write patches. Otherwise I'll move on. Good day. Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tty-ask-password-agent: return negative errno
Return negative errno in wall_tty_block(). get_ctty_devnr() already
returns a negative errno in case of failure, no need to negate it again.
Reported-by: Simon hw...@odai.homelinux.net
---
src/tty-ask-password-agent/tty-ask-password-agent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 1d067af..3203474 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -432,7 +432,7 @@ static int wall_tty_block(void) {
r = get_ctty_devnr(0, devnr);
if (r 0)
-return -r;
+return r;
if (asprintf(p, /run/systemd/ask-password-block/%u:%u,
major(devnr), minor(devnr)) 0)
return -ENOMEM;
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] gummiboot: build-sys: don't copy .eh_frame into final exe
Apparently some firmware implementations[1] won't run executables containing an .eh_frame section, failing instead with Error reported: Unsupported on the shell. There's also no obvious need for it, so don't copy it. [1] e.g., the one used on the ASRock C2750D4I --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index d224418..d004bdd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -144,7 +144,7 @@ $(efi_solib): $(efi_objects) $(efi_loadername): $(efi_solib) $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \ - -j .dynsym -j .rel -j .rela -j .reloc -j .eh_frame \ + -j .dynsym -j .rel -j .rela -j .reloc \ --target=efi-app-$(ARCH) $ $@ # -- -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
