Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1607342
| From | Petr Mladek <pmladek@suse.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread |
| Date | 2017-03-23 11:50 +0100 |
| Message-ID | <to8tz-116-1@gated-at.bofh.it> (permalink) |
| References | <ti0fn-8f0-15@gated-at.bofh.it> <ti0p3-8iJ-5@gated-at.bofh.it> <tnRCp-5tR-1@gated-at.bofh.it> <to5YK-7Ts-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu 2017-03-23 14:12:42, Sergey Senozhatsky wrote:
> On (03/22/17 17:40), Petr Mladek wrote:
> [..]
> > > +void console_printing_thread_off(void)
> > > +{
> > > + printk_kthread_disable++;
> > > + barrier();
> > > +}
> > > +
> > > +/* This re-enables printk_kthread offloading. */
> > > +void console_printing_thread_on(void)
> > > +{
> > > + barrier();
> > > + printk_kthread_disable--;
> > > +}
> >
>
> one observation here is that those functions neither turn off nor
> disable printk_kthread. we mark the point after which we will not
> wake_up printk_kthread, but that does not mean that printk_kthread
> is already or soon will be inactive. it actually can be in running
> state. so the name
Yup, allow/deny might might be better than on/off.
> hm, I certainly see what you meant here, but I suspect this naming may
> be a bit misleading - "so printk_deferred_mode_off() disables printk_deferred()?"
True, sigh.
> > Also it is an already know term and a more generic name. This API
> > is used globally while the kthread is an implementation detail.
> > The offloading might be done another way in the future.
>
> yes, this is why I avoided mentioning "printk_kthread" (directly)
> in API naming. console_printing_thread is sort of neutral (well,
> sort of). not insisting that the naming is perfect, of course.
It is too close to "printk_thread" used on different place.
So, it confuses me :-)
> the LOGLEVEL_SCHED thing is completely different tho. it tells us that
> neither of the above is safe -- both wake_up() and console_trylock()
> can potentially call into the scheduler. so I'm not sure we can easily
> replace LOGLEVEL_SCHED with `printk_kthread_disable'.
Grr, you are right. LOGLEVEL_SHED is deferred another way.
Let me do one more attempt for a generic name. What about?
printk_console_press(); or try_harder() or push()
printk_console_relax();
or something like this?
Best Regards,
Petr
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-03-22 17:50 +0100
Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-23 09:10 +0100
Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-03-23 11:50 +0100
Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-24 06:30 +0100
csiph-web