On Fri 2021-02-26 09:36:21, John Ogness wrote:
> On 2021-02-25, Petr Mladek wrote:
> > IMHO, a better design would be:
> >
> > 1. dumper->dump() callback should have only one parameter @reason.
> >The callback should define its own iterator, buffer, and
> >do the dump.
>
> Unfortunately
On 2021-02-25, Petr Mladek wrote:
> IMHO, a better design would be:
>
> 1. dumper->dump() callback should have only one parameter @reason.
>The callback should define its own iterator, buffer, and
>do the dump.
Unfortunately this won't work because drivers/mtd/mtdoops.c is using the
On Wed 2021-02-24 13:27:42, John Ogness wrote:
> On 2021-02-19, Petr Mladek wrote:
> > This is likely beyond the scope of this patchset.
>
> It would be beyond the scope of this patchset because it is not related
> to logbuf_lock removal.
>
> > I am still scratching my head about the
On 2021-02-24, John Ogness wrote:
> The @active flag is useless. It should be removed.
I would like to clarify my statement, because the @active flag _did_
protect the arch/um dumper until now. (Although it didn't actually
matter because arch/um does not have SMP or preemption support.)
In
On 2021-02-19, Petr Mladek wrote:
> This is likely beyond the scope of this patchset.
It would be beyond the scope of this patchset because it is not related
to logbuf_lock removal.
> I am still scratching my head about the synchronization if these dumpers.
>
> There is the "active" flag. It
On Thu 2021-02-18 09:18:12, John Ogness wrote:
> Rather than store the iterator information into the registered
> kmsg_dump structure, create a separate iterator structure. The
> kmsg_dump_iter structure can reside on the stack of the caller,
> thus allowing lockless use of the kmsg_dump
From: John Ogness Sent: Thursday, February 18, 2021
12:18 AM
>
> Rather than store the iterator information into the registered
> kmsg_dump structure, create a separate iterator structure. The
> kmsg_dump_iter structure can reside on the stack of the caller,
> thus allowing lockless use of the
On Thu 2021-02-18 09:18:12, John Ogness wrote:
> Rather than store the iterator information into the registered
s/store/storing/ ?
> kmsg_dump structure, create a separate iterator structure. The
> kmsg_dump_iter structure can reside on the stack of the caller,
> thus allowing lockless use of
8 matches
Mail list logo
