From: Esben Haabendal <esben@geanix.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: "Petr Mladek" <pmladek@suse.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Sergey Senozhatsky" <senozhatsky@chromium.org>,
linux-rt-users@vger.kernel.org,
"Martin Hundebøll" <martin@geanix.com>
Subject: Re: [PATCH 1/2] printk: export pr_flush()
Date: Wed, 03 Apr 2024 11:45:55 +0200 [thread overview]
Message-ID: <87v84yye24.fsf@geanix.com> (raw)
In-Reply-To: <87o7arpza0.fsf@jogness.linutronix.de> (John Ogness's message of "Tue, 02 Apr 2024 17:26:07 +0206")
John Ogness <john.ogness@linutronix.de> writes:
> On 2024-04-02, Esben Haabendal <esben@geanix.com> wrote:
>> Are there any other examples other than 8250 for how to port a driver to
>> nbcon?
>
> No. 8250 is the first example. And even this example is changing a bit
> with each new RT version as the underlying APIs and semantics have been
> changing.
>
>> What is the plans for porting all of this to mainline? Should all
>> drivers be ported first, or will a solution to prevent this type of
>> regression be implemented at some later time?
>
> First off, I want to mention that this behavior is only with the
> PREEMPT_RT preemption model. And it has been this way for a long
> time. The behavior of legacy consoles for other preemption models is the
> same as mainline now. So from a mainline perspective, I would not
> consider it a regression.
Got it. I think the last version where I know that this problem was not
seen with PREEMPT_RT was 4.19. And yes, that is a long time ago :)
> It is hard to say how this will actually play out though. We are
> bringing the printk/console rework to mainline piece by piece. Until now
> every piece has needed significant modifications in order to be accepted
> mainline. (This is the main reason the 8250 driver keeps needing
> changes.)
>
> The updated 8250 driver will be the last piece to go mainline. Only then
> would all the APIs, semantics, and documentation be official. Hopefully
> it is quite similar to what we have in the PREEMPT_RT tree now.
>
> I hope that once the printk/console rework is complete, there will be a
> big push to port over the other serial drivers. Most of them are just
> copy/paste of each other, which should simplify the porting. And since
> the new nbcon consoles provide real advantages, there will also be
> incentive to take on the porting effort.
>
> Finally, if someone wanted to try porting another driver for PREEMPT_RT
> (for example, the imx serial console), I would certainly be interested
> in reviewing and integrating the patches for the PREEMPT_RT tree.
Sounds good. I have looked at porting imx uart driver to nbcon, and have
something working now. It does smell quite a lot of copy-paste
behaviour, but I will send it as an RFC for you to see when I have
tested it a bit more.
The write_thread and write_atomic functions share quite a lot of code,
carrying half of the copy-paste smell.
The other half is the inner loop of the write_thread function, which is
almost identical in 8250 and imx drivers.
I guess there is room to refactor this to avoid this amount of
copy-paste before starting mass-porting.
/Esben
next prev parent reply other threads:[~2024-04-03 9:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 10:10 [PATCH 1/2] printk: export pr_flush() Esben Haabendal
2024-04-02 10:13 ` Esben Haabendal
2024-04-02 10:12 ` Esben Haabendal
2024-04-02 10:10 ` [PATCH 2/2] reboot: flush printk buffers before final shutdown Esben Haabendal
2024-04-02 10:13 ` Esben Haabendal
2024-04-02 10:12 ` Esben Haabendal
2024-04-02 10:25 ` [PATCH 1/2] printk: export pr_flush() John Ogness
2024-04-02 11:19 ` Esben Haabendal
2024-04-02 13:23 ` John Ogness
2024-04-02 14:41 ` Esben Haabendal
2024-04-02 15:20 ` John Ogness
2024-04-03 9:45 ` Esben Haabendal [this message]
2024-04-03 10:09 ` John Ogness
-- strict thread matches above, loose matches on Subject: below --
2023-10-30 9:24 Martin Hundebøll
2023-10-31 11:03 ` John Ogness
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v84yye24.fsf@geanix.com \
--to=esben@geanix.com \
--cc=john.ogness@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=martin@geanix.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.