Message ID | 20240904120536.115780-1-john.ogness@linutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | add threaded printing + the rest | expand |
On Wed 2024-09-04 14:11:19, John Ogness wrote: > Hi, > > This is v6 of a series to implement threaded console printing > as well as some other minor pieces (such as proc and sysfs > recognition of nbcon consoles). v5 is here [0]. > > For information about the motivation of the nbcon consoles, > please read the cover letter of the original v1 [1]. > > This series provides the remaining pieces of the printk > rework. All other components are either already mainline or are > currently in linux-next. In particular this series does: > > - Implement dedicated printing threads per nbcon console. > > - Implement forced threading of legacy consoles for PREEMPT_RT. > > - Implement nbcon support for proc and sysfs console-related > files. > > - Provide a new helper function nbcon_reacquire_nobuf() to > allow nbcon console drivers to reacquire ownership. > > Note that this series does *not* provide an nbcon console > driver. That will come in a follow-up series. JFYI, the patchset has been committed into printk/linux.git, branch rework/threaded-printk. I am not completely sure if we add this early enough for 6.12. On one hand, the patchset should not change the handling of legacy consoles and it does not add any nbcon console. But it touches many code paths where we decide how to flush the consoles and could imagine doing "ugly" mistakes there. OK, let's see how it works in linux-next in the following days. There is still time to catch problems and make the decision. Best Regards, Petr
On 2024-09-04, Petr Mladek <pmladek@suse.com> wrote: > JFYI, the patchset has been committed into printk/linux.git, > branch rework/threaded-printk. Thanks! > I am not completely sure if we add this early enough for 6.12. > On one hand, the patchset should not change the handling of legacy > consoles and it does not add any nbcon console. But it touches > many code paths where we decide how to flush the consoles > and could imagine doing "ugly" mistakes there. > > OK, let's see how it works in linux-next in the following days. > There is still time to catch problems and make the decision. I just don't think there are many real users of linux-next. The code leading to the 5.19 revert sat in linux-next for a long time and no one noticed anything. It wasn't until the 5.19-rc's started coming out that real testing (and bug reporting) occurred. I think linux-next is great for the kernel robots to work their magic, but I don't know if having something in linux-next for 6 weeks is any better than only 2 weeks. John