Re: [systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n
On Thu, 28.11.13 09:08, David Herrmann (dh.herrm...@gmail.com) wrote: A few comments beforehand: - regarding logging in libraries: I *want* verbose errors/warnings in sd-gfx. Especially if modesetting, keymap-compilation or bus-requests fail, I want some rather verbose messages in the log. Considering that if a single page-flip fails, I will not abort but continue the modeset (you don't want your console to abort due to minor timing issues in the DRM driver, right?), so the application might not even get an -EXYZ error value. I tried adding a -log_fn() like libudev, but then That libudev does that is mostly because it predates log.c, it wouldn't do that either anymore if we'd write it now... again, sd-gfx is internal so I skipped that and just called log_meta() directly. Is that fine for now? If not, I can change all these to log_debug() and make the applications more verbose. - new0(), zero(), ..., yepp, kay already told me but I forgot.. I will fix them up. - moving out parameters to the end... will do so. Hmm, interesting problem. I have the suspicion though that this either shouldn't be library code, or that they should be downgraded to debug level messages. 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] [RFC 00/12] Bugfixes for CONFIG_VT=n
On Wed, Dec 11, 2013 at 1:35 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 28.11.13 09:08, David Herrmann (dh.herrm...@gmail.com) wrote: A few comments beforehand: - regarding logging in libraries: I *want* verbose errors/warnings in sd-gfx. Especially if modesetting, keymap-compilation or bus-requests fail, I want some rather verbose messages in the log. Considering that if a single page-flip fails, I will not abort but continue the modeset (you don't want your console to abort due to minor timing issues in the DRM driver, right?), so the application might not even get an -EXYZ error value. I tried adding a -log_fn() like libudev, but then That libudev does that is mostly because it predates log.c, it wouldn't do that either anymore if we'd write it now... Hmm, for complex subsystems, error objects probably make the most sense, like we have for dbus. For things that really just want to log things from libraries, I still think that allowing to hook up the user of the library to its own logging facility makes some sense; instead of logging not enough, or just spitting things out on stderr. Not sure what a good advise is here for library, we should sort that out and also update libabc with that, if it's significantly different from what udev does. again, sd-gfx is internal so I skipped that and just called log_meta() directly. Is that fine for now? Please do not call log_meta() for debugging, unless you wrap it in your own macro to avoid composition of potentially expensive parameters to this function. Debug messages are usually thrown away, but only *inside* the function and all parameters need to be prepared to just get thrown away. For that reason, log_debug() wraps a check in it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n
Hi On Wed, Nov 27, 2013 at 11:44 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote: Looks pretty good. Commented on the invidiaul patches, but mostly looks good. I am not sure about the whole approach of making this a potentially public library though... Especially the monitor stuff sounds so specific. Commiting to a stable API for that given that there are very few other projects who could ever make use of this sounds dangerous at best. Especially since the api exposes bit values for enums and things, which makes me especially afraid... I have no short-term plan to export sd-gfx. It's just like the 3rd time I happen to write a DRM abstraction and I really don't wanna do that again. Hence, I thought putting it into sd-gfx would reduce the burden to export it eventually. Furthermore, as there'll be like 5 daemons using it, it would be nice to have a clean API even if it's only systemd-internal (it forces one to write better code, imho). Last but not least, it makes debugging easier if there's a clean cut between sd-gfx and each application. But: the current API will never get exported as it is. Obviously, the monitor (and probably font) is better kept internal. But I see no reason to add sd-gfx-internal.h / sd-gfx-internal.la now. In case we ever export it, we would have to decide which parts to split off (which is a rather mechanical tasks, so no reason to account for it right now). So lets just say I hate camel-case object-names so I went for libsystemd-gfx to have an excuse to use lower-case-separated-by-underscore names, right? Lets treat sd-gfx as internal library for now. A few comments beforehand: - regarding logging in libraries: I *want* verbose errors/warnings in sd-gfx. Especially if modesetting, keymap-compilation or bus-requests fail, I want some rather verbose messages in the log. Considering that if a single page-flip fails, I will not abort but continue the modeset (you don't want your console to abort due to minor timing issues in the DRM driver, right?), so the application might not even get an -EXYZ error value. I tried adding a -log_fn() like libudev, but then again, sd-gfx is internal so I skipped that and just called log_meta() directly. Is that fine for now? If not, I can change all these to log_debug() and make the applications more verbose. - new0(), zero(), ..., yepp, kay already told me but I forgot.. I will fix them up. - moving out parameters to the end... will do so. Thanks for the review. Few more comments on the individual patches. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n
Hi So booting without VTs is still a horrible experience on desktop-linux. If anyone tried, they were presumably running away in tears. This series is a new attempt to fix that. The first 4 patches are just small fixes/helpers. Patch 5 to 8 introduce sd-gfx and patch 9-11 add tests/examples for sd-gfx. The final patch adds a first user of sd-gfx to replace the kernel-internal terminal-emulator. The commit-msgs should explain each change at length so I won't repeat it here. To anyone interested in testing: If you apply this series, you can run ./test-kbd to test keyboard handling, ./test-gfx to test graphics rendering and ./systemd-consoled to run the terminal-emulator. Note that you must run all these from *within* an existing logind-session. That usually means from a TEXT-VT. Also note that all these programs currently ignore the underlying VT entirely (in case you run with CONFIG_VT=y). This has the side-effect, that all keystrokes go to both, the VT and the application. This will obviously be changed in later versions, but I wanted to avoid any VT calls in these helpers. I currently work on logind to fix that. I had to strip the font-patches due to ML size-constraints. The full series is always available on the-often-rebased-console-branch at: http://cgit.freedesktop.org/~dvdhrm/systemd/log/?h=console Notes on where this is going, and *why*, below.. Happy Testing! David What is wrong with CONFIG_VT? = The VT layer in the kernel implements a rather complex keyboard layer (similar to XKB, but less powerful), implements hard-coded device hotplug filters, input handling, graphics-pipeline handling, font-rendering, terminal-emulation, cursor handling and more. All this is used to render a basic text-UI *in the kernel*! However, moving UI handling into the kernel has a lot of disadvantages (the same reason why user-space exists.. look it up). For completeness, some rather obvious reasons are: - non-swappable memory (even if you have no swap-partition, user-space apps can avoid loading all fonts/keymaps into memory, which kernel-space cannot) - security critical (any bug in the UI layer may allow *kernel-level* privileges to attackers) - stability (user-space apps can be easily restarted on failure; in kernel-space, all kinds of memory may get overwritten..) - code-duplication (we already have all this code in user-space, why copy it into kernel-space?) - simplicity (we wanna keep the kernel simple and slim, which prevents adding more complex features like fully internationalized fonts and keymaps, which are *required* for emergency consoles with given keyboards) - configurability/controllability (ever tried assigning more/less CPU-time to a given VT?) - ... So what reasons exist to have a UI layer in kernel-space? I only found 3 reasons, if someone knows more, let me know. I highly doubt there's more.. 1) Early boot debugging 2) Panic/Oops screen 3) kdb kernel debugging For 1) and 2) we have an experimental fblog/drmlog kernel module which just prints the kernel log to all screens. This only requires ASCII glyphs and raw access to DRM FBs. All the VT cruft can be dropped.. For 3): You're welcome to enable CONFIG_VT if you need a terminal-emulator for kernel-debugging. My experience is that a serial-console is far more helpful and reliable and avoids calling DRM modesetting in atomic-context (ugh? This fact really makes me doubt anyone uses kdb.. Use kgdb!). Long-term plan == So the long-term plan for this series is to set CONFIG_VT=n. This actually already works and you can boot your machine and start sessions like kmscon. Even Xorg works if you apply a one-line patch. However, without VTs, legacy sessions like Xorg will run in exclusive mode. To allow session switching, you need systemd-logind. But even session-switching is already implemented. Though, no real application uses that, yet (except for weston and some example code). So most of the work is to fix all these applications to support VT-less mode. This is already ongoing and will work soon (hopefully..). So what does this series implement? Well, if you run without VTs, you lack any kind of fallback console or fallback login-screen. To guarantee that even without VTs there's a system-console and login-screen, this series adds the most basic implementations of those to systemd. This will *never* turn into a full-blown full-featured console. No eye-candy, no useless features, NO BACKGROUND IMAGES!!! The idea is to provide a fallback in systemd. If you want a fancy console with more features, install kmscon and it will simply replace the systemd-fallback. However, that means more memory-footprint, more CPU-requirements and a lot more dependencies. sd-gfx is a helper library in systemd to unify all the graphics, screen and font handling. All following applications will use it, including: (daemon-names are subject to change!) - systemd-consoled: A systemd console
Re: [systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n
On Wed, Nov 27, 2013 at 07:48:35PM +0100, David Herrmann wrote: Hi So booting without VTs is still a horrible experience on desktop-linux. If anyone tried, they were presumably running away in tears. This series is a new attempt to fix that. The first 4 patches are just small fixes/helpers. Patch 5 to 8 introduce sd-gfx and patch 9-11 add tests/examples for sd-gfx. The final patch adds a first user of sd-gfx to replace the kernel-internal terminal-emulator. The commit-msgs should explain each change at length so I won't repeat it here. To anyone interested in testing: If you apply this series, you can run ./test-kbd to test keyboard handling, ./test-gfx to test graphics rendering and ./systemd-consoled to run the terminal-emulator. Note that you must run all these from *within* an existing logind-session. That usually means from a TEXT-VT. Also note that all these programs currently ignore the underlying VT entirely (in case you run with CONFIG_VT=y). This has the side-effect, that all keystrokes go to both, the VT and the application. This will obviously be changed in later versions, but I wanted to avoid any VT calls in these helpers. I currently work on logind to fix that. I had to strip the font-patches due to ML size-constraints. The full series is always available on the-often-rebased-console-branch at: http://cgit.freedesktop.org/~dvdhrm/systemd/log/?h=console Notes on where this is going, and *why*, below.. Very nice work, keep it up. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n
On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote: Looks pretty good. Commented on the invidiaul patches, but mostly looks good. I am not sure about the whole approach of making this a potentially public library though... Especially the monitor stuff sounds so specific. Commiting to a stable API for that given that there are very few other projects who could ever make use of this sounds dangerous at best. Especially since the api exposes bit values for enums and things, which makes me especially afraid... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
