Message ID | 20220924000454.3319186-1-john.ogness@linutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | preparation for threaded/atomic printing | expand |
On Sat, Sep 24, 2022 at 02:10:36AM +0206, John Ogness wrote: > Hi, > > This series is essentially the first 18 patches of tglx's RFC series > [0] with only minor changes in comments and commit messages. It's > purpose is to lay the groundwork for the upcoming threaded/atomic > console printing posted as the RFC series and demonstrated at > LPC2022 [1]. > > This series is interesting for mainline because it cleans up various > code and documentation quirks discovered while working on the new > console printing implementation. > > Aside from cleanups, the main features introduced here are: > > - Converts the console's DIY linked list implementation to hlist. > > - Introduces a console list lock (mutex) so that readers (such as > /proc/consoles) can safely iterate the consoles without blocking > console printing. > > - Adds SRCU support to the console list to prepare for safe console > list iterating from any context. > > - Refactors buffer handling to prepare for per-console, per-cpu, > per-context atomic printing. > > The series has the following parts: > > Patches 1 - 5: Cleanups > > Patches 6 - 12: Locking and list conversion > > Patches 13 - 18: Improved output buffer handling to prepare for > code sharing > These all look great to me, thanks for resending them. Do you want them to go through my serial/tty tree, or is there some other tree to take them through (printk?) If they are to go through someone else's tree, feel free to add: Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On (22/09/24 02:10), John Ogness wrote: > > Patches 6 - 12: Locking and list conversion > A quick question: I wonder why xenfb_make_preferred_console() isn't converted to list lock and for_each_registered_console()?
On 2022-09-24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > These all look great to me, thanks for resending them. > > Do you want them to go through my serial/tty tree, or is there some > other tree to take them through (printk?) Thanks Greg. but I would prefer they go through the printk tree. In particular, I want Petr to have the chance to review patches 15-18. > If they are to go through someone else's tree, feel free to add: > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks! John
On Sat 2022-09-24 02:10:36, John Ogness wrote: > Hi, > > This series is essentially the first 18 patches of tglx's RFC series > [0] with only minor changes in comments and commit messages. It's > purpose is to lay the groundwork for the upcoming threaded/atomic > console printing posted as the RFC series and demonstrated at > LPC2022 [1]. > > This series is interesting for mainline because it cleans up various > code and documentation quirks discovered while working on the new > console printing implementation. > > Aside from cleanups, the main features introduced here are: > > - Converts the console's DIY linked list implementation to hlist. > > - Introduces a console list lock (mutex) so that readers (such as > /proc/consoles) can safely iterate the consoles without blocking > console printing. > > - Adds SRCU support to the console list to prepare for safe console > list iterating from any context. > > - Refactors buffer handling to prepare for per-console, per-cpu, > per-context atomic printing. > > The series has the following parts: > > Patches 1 - 5: Cleanups > > Patches 6 - 12: Locking and list conversion > > Patches 13 - 18: Improved output buffer handling to prepare for > code sharing > > Thomas Gleixner (18): > printk: Make pr_flush() static > printk: Declare log_wait properly > printk: Remove write only variable nr_ext_console_drivers > printk: Remove bogus comment vs. boot consoles > printk: Mark __printk percpu data ready __ro_after_init JFYI, I have pushed the first 5 cleanup patches into printk/linux.git, branch rework/kthreads. The aim is to get them into 6.1. The rest of the patchset is still being discussed. Best Regards, Petr