Messages in this thread | | | Date | Fri, 17 May 2024 15:31:28 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH printk v5 06/30] printk: nbcon: Add callbacks to synchronize with driver |
| |
Hi,
On Thu 2024-05-02 23:44:15, John Ogness wrote: > Console drivers typically must deal with access to the hardware > via user input/output (such as an interactive login shell) and > output of kernel messages via printk() calls. To provide the > necessary synchronization, usually some driver-specific locking > mechanism is used (for example, the port spinlock for uart > serial consoles). > > Until now, usage of this driver-specific locking has been hidden > from the printk-subsystem and implemented within the various > console callbacks. However, for nbcon consoles, it is necessary > that the printk-subsystem uses the driver-specific locking so > that nbcon console ownership can be acquired _after_ the > driver-specific locking has succeeded. This allows for lock > contention to exist on the more context-friendly driver-specific > locking rather than nbcon console ownership (for non-emergency > and non-panic cases).
Honestly, the above paragraph is kind of a puzzle. My first understanding was that the driver-specific lock will always need to be taken before acquiring the nbcon console ownership.
I believe that it is actually correct. But the right meaning is hidden in the wording. I had to read it many times to get it correctly and I knew what I was looking for.
I have to admit that providing a good explanation is probably very hard. A proof is the long discussion in v4, see https://lore.kernel.org/r/20240402221129.2613843-7-john.ogness@linutronix.de
BTW: I wonder if you use AI for generating the commit message. My experience is that AI produces longer fancy sentences which might be good for a novel but they sometimes hide the important details.
> Require nbcon consoles to implement two new callbacks > (device_lock(), device_unlock()) that will use whatever > synchronization mechanism the driver is using for itself. > > Signed-off-by: John Ogness <john.ogness@linutronix.de>
My attempt of a more strightforwward explanation:
<proposal> Console drivers typically must deal with access to the hardware via user input/output (such as an interactive login shell) and output of kernel messages via printk() calls. To provide the necessary synchronization, usually some driver-specific locking mechanism is used (for example, the port spinlock for uart serial consoles).
Until now, usage of this driver-specific locking has been hidden from the printk-subsystem and implemented within the various console callbacks. However, nbcon consoles would need to use it even in the generic code.
Add device_lock() and device_unlock() callback which will need to get implemented by nbcon consoles.
The callbacks will use whatever synchronization mechanism the driver is using for itself. The minimum requirement is to prevent CPU migration. It would allow a context friendly acquiring of nbcon console ownership in non-emergency and non-panic context. </proposal>
That said, I could live even with the original commit message. Eitherway:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards, Petr
| |